The Shared Responsibility Model for Security in The Cloud (IaaS, PaaS & SaaS)

Cloud security incidents are skyrocketing. In fact, nearly half (45%) of all security incidents target cloud-based services. Another angle: 80% of business organizations experienced at least one cloud security breach incident last year. (Arguably the worst part here is that, when a system is breached, the average dwell time is 9 weeks.)

Still, over 72% of businesses plan to continue investing in the cloud. So how do you make cloud computing a secure environment for sensitive business information?

The answer is the shared responsibility model. Its name makes it clear: in the shared responsibility model, the customer and the vendor share responsibilities. But which ones belong to who? And how did we get to this spot?

Let’s look at both sides of cloud computing and we’ll see where the shared responsibility model lands.

Opposition: The security of cloud computing

Critics of cloud computing believe that sensitive business information should never leave the IT networks operated and controlled within your own in-house data centers. And compliance regulations mandate similar security measures in some cases — restricting the use of public cloud services running on data centers that run in another country, for instance.

This makes sense as any data transmitted over public networks is subject to cybersecurity risks. Any security vulnerability within the network of the cloud vendor can expose your information to security risks. Plus, you no longer control how the underlying systems are maintained, managed, upgraded and improved for security.

In favor of cloud security

Proponents of cloud computing present a compelling argument against this concern: multi-billion cloud vendors are better suited to handle sensitive business information for two main reasons:

• They understand the prevalent risk.
• The employ sophisticated defense mechanisms to protect user data.

An average SMB firm may not face a similar magnitude of cybersecurity risks, but they also cannot rival established tech giants in securing information within large cloud-based data center systems.

So which perspective is more compelling?

• With the first perspective, you’re fully responsible for your own cybersecurity within internal data center systems. That means you’re spending money, time and resources building out the talent and the technology you need to support cybersecurity.
• Following the second perspective, it seems naive to trust a third-party vendor for the full cybersecurity responsibility. Lower cost, lower control.

The shared responsibility model: meeting in the middle

In practice, the cloud computing industry meets in the middle: it offers limited visibility and control into the infrastructure systems, which are managed and operated by the vendor. However, they offer the necessary security tooling and capabilities that give a user control over the security of their own data.

As such, they follow a shared security responsibility model, where both the cloud vendor and customer are expected to adopt certain security controls depending on the type of service.

Security controls in a shared responsibility model

These security controls usually run along these lines:

What the cloud vendor is responsible for

The cloud vendor manages, operates and controls the infrastructure operations from the virtualization layer all the way to the hardware device security. These include:

• The storage and compute systems
• Networking systems
• Databases
• The physical data centers

There are plenty of cloud vendors out there, and of course you’ll recognize the Big 3 of AWS, Azure and GCP.

What the customer is responsible for

The cloud customer — you, or your organization — is responsible for managing the security of data and the guest operating system, including:

• Identity and Access Management (IAM) controls
• OS configurations
• Security policies
• Firewall
• Other features available on the frontend

Customers must encrypt the data and adopt authentication systems to ensure security of their workloads based on the necessary security policies.

Are any functions shared?

Depending on the cloud vendor, some security functions may be shared. These include security training and awareness, patch management and configuration management — both the cloud vendor and customer share the security responsibilities for resources they control.

Shared responsibilities vary in SaaS, PaaS & IaaS

So, that’s a brief rundown of shared responsibility, but when it comes to security, there is some variation. Security responsibilities vary between different cloud service classifications: IaaS, PaaS and SaaS. Here’s the general rule of thumb:

• For infrastructure as a service (IaaS), the user is responsible for the most resources, from the application layer to the network layer, where responsibility is shared with the vendor.
• For platform as a service (PaaS), the shared vendor responsibility includes IAM and storage, but excludes the application layer.
• For software as a service (SaaS), the customer is only responsible for securing application configurations while IAM becomes a function of the shared responsibility model.

Yet, these responsibilities can vary depending on the vendor, service offering and contract with the cloud vendor. So, whichever vendor(s) you’re investigating, be sure to ask for their breakdowns of shared responsibilities.

Above is Splunk Protects, our overall portal for data privacy, security and compliance. We especially like TechTarget’s graphic breakdown:

Shared responsibility best practices

It’s therefore best to follow standard practice when it comes to cloud security responsibility:

• Understand how well the service meets your security requirements.
• Depending on the available controls, you are expected to fully configure the service for security.
• Select which data assets are moved to the cloud.
• Access controls and policies that not only ensure that authorized users are able to access your data, but they do so in compliance with the principle of least privilege access — permission to access only the service and data they need to fulfill the authorized task.
• Adopt encryption protocols for security sensitive data so that in event of a security breach, your data remains unintelligible.
• You are responsible for securing the endpoint devices and accounts. Compromised devices and accounts can overcome any security defense that is designed to prevent external attackers from a network intrusion.

You can, however, shift and modify responsibilities to the cloud by:

• Using cloud-based security tools.
• Employing a cloud managed service provider.
• Reallocating resources to the cloud.

The latter corresponds to adopting a cloud-native approach to software development, using microservices and PaaS instead of using in-house private cloud deployments, for instance.

It’s also important to understand that delegating security responsibility to the vendor — such as by avoiding an IaaS service in favor of a more managed PaaS or even SaaS service — can also potentially lead to vendor lock-in.

What is Splunk?

This posting does not necessarily represent Splunk's position, strategies or opinion.