Shared Security Model

Cloud security refers to the efforts of securing applications, data and infrastructure. It has become a priority owing to concerns over data exposure. 

A shared security model gives a framework for cloud security for sharing the security responsibilities between the cloud service provider and the user to ensure accountability.

The challenge for an organization is to secure the applications and the data that moves between various clouds, at the same time not ignoring the organization’s need for agility. It is imperative for organizations to fight external as well as lateral attacks across all locations where data and applications reside. 

An organization in itself has many teams that could be responsible for cloud security, such as: network team, application team, security team or the infrastructure team. 

However, cloud security is also a shared responsibility between the organization and its cloud vendor. 

What is a shared security model?

In simple terms, the shared security model specifies the responsibilities of both the cloud service providers and their customers when it comes to securing the cloud. It is important to define where exactly the line resides. 

During the time of on-premise data centers, the entire security responsibility for the server would fall be of the organization only. But, as more and more organizations shift their data to the cloud, it becomes imperative that the security responsibility is shared between the cloud service provider and the user. 

The figure below explains how the responsibilities are shared between the cloud service provider and its user. 

Shared security model in cloud security

Some customer responsibilities such as administrative privilege control, audit log maintenance, data recovery, incident response and application security awareness are always retained by the user.

Defining the lines in a shared responsibility model.

The share of responsibility for your organization depends on the cloud service model that you have chosen from your provider. The three main cloud service models are Infrastructure-as-a-service (IaaS), Software-as-a-service (SaaS) and Platform-as-a-service (PaaS). Each of these models  have different implications for shared responsibility.

Infrastructure-as-a-service (IaaS)

In this, the cloud service provider provides access to cloud based hardware resources. Under this architecture, it’s pretty clear that the cloud service provider is responsible for the security of the infrastructure i.e. physical plant security and resilience. The customers are responsible for securing the operating systems, servers, network configuration, access control as well as the applications and data that they choose to run on that infrastructure.

Examples of IaaS are AWS EC2, Microsoft Azure.

Software-as-a-service (SaaS)

In this, the cloud service provider provides the host infrastructure as well as the software. Hence the responsibility for ensuring that the SaaS application is free of vulnerabilities shifts to the provider. Also the provider is typically responsible for securely storing any customer data that the SaaS application ingests. Whereas the customers are responsible for securing any data they download from it as well as securing access to it. 

Examples of SaaS are Google GSuite, Dropbox.

Platform-as-a-service (PaaS)

PaaS blends SaaS and IaaS together. In this the cloud service provider is responsible for securing any underlying infrastructure that hosts the PaaS offering, but the responsibility for securing software testing and deployment environments lies with users. 

Examples of PaaS are AWS Elastic Beanstalk, Google app engine.

Given that most major providers offer IaaS, SaaS and PaaS solutions, in order to understand how shared responsibility breaks down between you and your provider you need to understand which type of offering you are using. 

According to ‘Cloud standards customer council’ your responsibility increases as you move from SaaS to PaaS to IaaS. While it may seem that you are responsible for a significant portion of the cloud security, your provider does reduce your burden by taking 100% control of the responsibility of certain areas depending on the service model you choose.

For example, for IaaS services such as Amazon Elastic Compute Cloud (EC2), the customer is required to perform all the necessary security configuration and management tasks i.e.  management of the guest operating system, any application software or utilities installed by the on the instances and the configuration of the AWS-provided firewall on each instance.

For services such as Amazon S3 and Amazon DynamoDB, Amazon web services operates the infrastructure layer, operating system and the platforms. Customers are responsible for managing their data, classifying their assets and using  Identity and access management tools to apply the appropriate permissions.

Shared responsibility in multi and hybrid cloud environments.

Many organizations using multiple clouds at once complicates shared responsibility, especially in cases where some workloads run in a private cloud and others in a public cloud. 

Say, you have some of your applications running on a private cloud and others on a public cloud. In such cases, the conventional shared responsibility model is applied only to the public cloud portions of your workload. The entire responsibility of securing the private cloud lies on you alone as both the infrastructure and workloads running on it is managed by you. 

In case you are using multiple public clouds, all your service providers should follow the same shared responsibility guidelines. 

The extent to which a provider secures your data and workloads depends on the category of cloud service you are using. Thus, if you are using both AWS (for IaaS) and Azure(for SaaS), then both these providers will provide different levels of security services.

Shared security for DevOps pipeline

The speed at which your business delivers new applications and features is enhanced if the cloud applications are powered by an automated CI/CD pipeline and driven by a DevOps organization. Sadly, that also means that without proper consideration and management your DevOps pipeline can introduce security vulnerabilities. In a shared responsibility model, the responsibility of securing your code and the tools you use to deliver applications to the cloud is yours. Beyond securing your CI/CD pipeline, you should leverage CI/CD automation processes to shift security left. This idea of “shifting left” means that new vulnerabilities are caught and remediated before being introduced into a production service.

Conclusion

Every time your cloud provider takes a portion of security responsibility, it directly reduces the security concerns for your organization. You can focus more on application delivery strategy without putting any extra burden for your team with the day to day operational concerns in the physical layer.

One of the most common cloud security myths is that a provider will handle all of the cloud security a company needs. You should assume that depending on the cloud service model you use, you are responsible for securing everything and anything that you have the power to secure. That approach will mitigate the risk that some security considerations might fall through the cracks, because neither your provider nor you deal with them adequately.

We at technosprout have partnered with the best security solutions for you. Do visit our website to know more about how you can enhance your cloud security.