“What is my security responsibility in the cloud when I am using IaaS, PaaS and/or Serverless application?” This is one of the most common questions we get asked by companies that are considering moving to the cloud and/or modernize their application with micro service architecture. This is because, today the application uses multiple services from single/multiple cloud service provider and each service in cloud has different shared security responsibility.
Shared security responsibility in the cloud environment change based on application architecture and type of cloud services it integrates to. Generally speaking, the cloud service provider, such as AWS or Azure, takes care of the infrastructure and security of the cloud. The customer, on the other hand, is responsible for securing everything in the cloud.
This shared responsibility model gives businesses the ownership and control of their data, applications, and operating system, just like in the on-premise environment. But not all cloud services provide same type of controls on operating system platform. It means that companies that are using PaaS, and containerized application have different security responsibility than companies using pure IaaS and/or Serverless applications.
The companies may find themselves confronted by different security challenges as they move through different stages of cloud adoption. Therefore, it is important for CISOs and solution architects to create threat modelling for the evolving application architecture in the cloud.
The three stages of cloud adoption and application evolution include:
Stage one: Threat vector in monolithic applications in the cloud
For the longest time ever, the monolithic architecture had been the default application development pattern. Its single codebase approach brings about ease of development, deployment, and testing. On top of that, developers are familiar with the architecture.
Application code in the cloud isn’t just written by the company. As with all modern web applications, developers use third party – mostly open-source – components, typically including web frameworks and libraries. These third-party components have security vulnerabilities of their own.
Security for monolithic applications revolves around authentication, authorization, and encryption. As a result, by using vulnerability-laden third-party components, hackers can launch attacks at the security processes, thereby rendering them invalid, compromising the security for the whole architecture.
Stage two: Threat vector in containerized applications and PaaS
When the cloud journey evolves, applications start to become loosely coupled and stateless in nature. Applications also begin to integrate with other cloud services like object storage, caching services, and NoSQL databases. From these evolutions sprang the micro services architecture, where modules become small, individual application entities in containers, and they communicate over RESTful API. The APIs add another layer that needs to be secured with run-time application self-protection.
While developers follow the Agile methodology and release new application updates every day, DevOps team uses containers to achieve continuous integration and continuous delivery (CI/CD). This process can hinder security team’s visibility, as many moving components are used by developers and/or the DevOps team inside containers.
If companies don’t have visibility into the threats, they can’t apply security controls to the system. Since containerized micro service applications remove visibility for the teams who follow traditional security methods, it’s important to integrate security into the DevOps process.
Stage three: Threat vector in serverless applications
In the serverless model, companies who own the systems don’t have to purchase or rent servers or virtual machines to run the code. Serverless architecture is heavily dependent on third-party services. The best-known vendor host currently is AWS Lambda and Azure/GCP Functions.
The shared responsibility model in serverless application becomes more complex from a security compliance standpoint. The threat vector is different in a serverless application, from monolithic or micro service application architecture. This requires the company think about security from an application design perspective.
In order to access other cloud services, serverless function needs to be configured with identity roles and the permission, be provided by the cloud provider. Such infrastructure privilege access to function code can become a new threat vector if access to function trigger (external APIs) is not hardened.
Serverless functions on different cloud platforms are configured differently. For Example, While AWS Lambda and GCP functions provides serverless functions with basic library and default language support, Azure’s function requires different configuration for each language version and libraries from KUDU shell access. These variations can change the threat vector for different cloud service providers.
Such new type of security risk is causing new type of attack e.g. Denial of wallet and attacks on application code and library. Securing serverless application requires protection run-time application self-protection (RASP) and another API security configuration.
In summary, although security needs vary at different stages of the cloud adoption lifecycle, when it comes to different types of applications, basic principles for security remain the same. Visibility is the key to applying security controls on any threat vector. Integrity monitoring of file system and log analytics can help to provide visibility on threat vectors.
Vulnerability scanning and applying patch and virtual patch are mandatory steps throughout the cloud journey. Intrusion prevention system and intrusion detection system (IPS/IDS), monitoring possible control and command (C&C) connection, and firewall can be used to identify and mitigate threats at the initial phase of the intrusion kill chain.
By: Tejas Sheth, Cloud Security Architect, Trend Micro
