Application Security in the Public Cloud Requires Shared Responsibility

The Growth of Public Cloud

Since 2006 when Amazon first introduced EC2 — the first public cloud service — cloud has become a major staple of enterprise information technology strategy. Both Infrastructure as a Service (IaaS) and newer cloud services continue to grow robustly.

While providing undeniable benefits to users such as scalability, speed to market, and cost savings, public cloud offerings also created a new dilemma: Just who was responsible for security when the platform was no longer protected on the user’s  premises,  and was in some part controlled by a third-party vendor?

Cloud security is an issue the industry has had to solve in order to achieve such impressive growth. Since 2014, security services have been a key focus area of cloud providers. This includes protection of the infrastructure itself and tenant boundaries, as well as advanced services protecting the data itself. Without security, no reasonable enterprise would use public cloud in production.

AWS Approach To Shared Responsibility Model

As a public cloud pioneer, Amazon Web Services (AWS) was the first provider to introduce the term “shared responsibility model” and its components, starting to think about improving  cloud security to a level sufficient to protect enterprise production workloads.

According to Amazon:

‍“Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve customer's operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.”

In short, AWS secures the cloud’s physical infrastructure, compute, and network systems  from outside physical access and from digital access and insider threats.  The customer’s responsibility is to protect everything they run in the cloud.

What Needs To Be Secured in a Cloud Deployment?

The importance of security in the context of public cloud has led to formation of the Cloud Security Alliance (CSA). CSA has their own interpretation of the shared responsibility model.

From the CSA’s perspective, the following are the categories of cloud systems that need to be secured:

Information and Data - Data are the crown jewels of any digital business. From the addresses of paying customers to sensitive financial records and employees’ information ,  protecting data is critical to the success of any online business. Further, many compliance regulations, especially the recent focus on GDPR and CCPA, exert additional pressure to protect personally identifiable information.

‍Application Logic, APIs, and Code - The data are interpreted and processed by the application logic and application programming interfaces, or APIs. The code that implements applications can represent a core competitive advantage for the enterprise, but the logic itself and protection of the APIs is extremely important for securing  both the business and its data.

‍Users, Authentication, and Access Control - Users — who are both owners of the data and the source of revenue for the online business — , also need protection. From account takeover to identity theft, malicious actors can harm the users. The owner of the service where such attacks take place  is ultimately responsible for providing security.

‍Platform and Resource Configuration - This is the only major component of the cloud that is protected by the cloud provider itself. Protection is typically extended to the physical premises, computing resources, including cooling and physical maintenance requirements, network resources, virtualization systems and hypervisors, resource management systems, storage systems and so on.

As Platforms Evolve, Does Shared Responsibility Change as Well?

Newer cloud services go beyond providing just infrastructure-as-a-service and may influence how we think about shared responsibility.

For example, some of the more interesting platform offerings include serverless compute services, a cloud development model that allows developers to build and manage applications without having to worry about server management. These offerings include  AWS Lambda, AI-as-a-service, (such as Google Cloud AI), and hosted blogs like Medium.

If the application uses one of these advanced services, it changes how the shared responsibility model is applied because the provider is not just responsible for the host, but also for the security of the platform itself.

While this helps us sort out security responsibilities, we must still consider security of information and data (think hosted Wordpress blog); security of intellectual property and code (such as the case with serverless);  and security of the API and application logic (as might be the case with a hosted Kubernetes infrastructure, Amazon Elastic Kubernetes Service or Azure Kubernetes Service). All these data, application logic and code elements should still be secured by the cloud user or enterprise according to the shared responsibility model.

There are a couple of additional important security considerations for newer platforms. Watch out for cloud lock-in. While running a guest Linux OS makes it extremely easy to migrate  workloads back on premises or to a different cloud, running the logic on a hosted platform makes the migration more difficult: the logic becomes dependent on the provider APIs. Secondly, data flows and compliance becomes a touch more difficult because best practices are not as well established for newer platforms.

How Traceable Can Help

Traceable Defense AI provides application protection that helps fill in the customer’s share of the shared responsibility, especially as data flows, application logic, and APIs are concerned.

Data flows - Traceable observes the data flows throughout the application running on the platform and identifies sensitive data for compliance purposes.

API security in pre-production and production - Traceable maps out the application flows, protects applications and APIs from run-time threats, assesses API risks and helps with threat analysis and compensating controls.

User-centric view - Traceable identifies suspicious activities and anomalies. When suspicious activity is detected on a previously well-behaved account, it’s an indicator of an account compromise. Combined with a rate-limiting functionality, this helps protect legitimate users.

Traceable is a born-in-the-cloud company that prides itself on helping enterprises adopt cloud-native architectures in production. Understanding the shared responsibility model, selecting the cloud provider that holds up their end of the bargain, and using the right security tools to fulfill the enterprise share of security responsibility is what will make the cloud truly secure.

To learn more about Traceable you can visit us at https://traceable24dev.wpenginepowered.com or view a recorded demo.