Shared Responsibility Doesn’t Make Security Someone Else’s Problem

Too many IT professionals seem to think that “shared” security actually means “I don’t have to worry about security.”

Nothing could be further from the truth.

From the moment your organization spins up its first instance in Amazon Web Services, Microsoft Azure or Google Cloud Platform, you have become a participant in the shared security model. Understanding this model is what makes the difference between a protected environment, and one that is open to attack.

What is shared security?

As the name suggests, shared security is when two parties are responsible for the security posture of a single computing environment. In the public cloud (IaaS), the breakdown of responsibility here involves the provider guaranteeing physical security for the servers, storage, network, virtualization software and other infrastructure while the client takes on the task of ensuring proper security configurations using a suite of built-in tools and processes as well as third-party platforms.

What is the provider responsible for?  

Before the cloud, you were responsible for deploying, managing and protecting on-premises data centers for your IT requirements. You had to make sure nobody could break into the room and that enough redundancies were in place to ensure that a fire, flood etc. wouldn’t wipe everything away. You then bought and secured the servers, storage arrays, switches and routers, etc., installed and patched the hypervisor, and finally got around to deploying and managing the databases, web servers and applications.

When you join these public clouds you are placing your data onto the most physically secure servers that have ever existed. The leading public cloud providers such as Amazon Web Services (AWS), Google and Microsoft spare no expense when it comes to the protection of their products. In fact, Micrsoft is known to spend upwards of $1 billion a year on security for its products.

That type of money is getting spent on creating innovative online and on-prem security solutions that rival high-level government institutions. For example, in a white paper Amazon described some of the security measures it employs at its own server farms across the country. The measure include strict physical access controls, high-end surveillance, intrusion detections, temperature controls, fire suppressants and power redundancies.

When it comes to physical security for your data, there’s no question that joining up with the public cloud is the way to go. However, there’s a lot more to keeping your environment secure than fancy locks and fire extinguishers.

That’s where you come in.

What am I responsible for?

Depending on the type of cloud system you are running (IaaS, SaaS, PaaS, etc.) you will be responsible for different aspects of your environments security posture. However, what most of your tasks will boil down to is this: configuration and compliance.

Providers like Amazon and Microsoft make it clear in their documentation that when they say shared security they mean shared security. Microsoft explains the breakdown clearly in a paper: “Ensuring that the data and its classification is done correctly and that the solution will be compliant with regulatory obligations is the responsibility of the customer.”

For example, consider Identity & Access Management. When using Azure, AWS or GCS it’s up to you to make sure that services such as multi-factor authentication are properly fine-tuned and maintained. However, ensuring the effective functionality of these tools is the responsibility of the provider.

You can replace provider-specific terms like Azure Active Directory Services with equivalents like AWS IAM protections, but the essence is the same for all the major cloud providers: we’ve provided you with tools to configure your data securely, but it’s up to you to use them well.

Not surprisingly, IaaS services require the most work on your part. According to Amazon:

“[IaaS] services such as Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), and Amazon S3 are categorized as Infrastructure as a Service (IaaS) and, as such, require the customer to perform all of the necessary security configuration and management tasks. If a customer deploys an Amazon EC2 instance, they are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance.”

Nailing these security procedures and mastering the tools that the providers make available to customers is essential to creating an airtight ecosystem. Unfortunately, this is also where most professionals miss the mark.

Shared security misconceptions:

There has been a growing gap in understanding and proper execution when it comes to cloud infrastructure security. Most companies moving to an IaaS environment understand that the cloud service provider is responsible for physical infrastructure security. They also understand that they are responsible for workload security, e.g., keeping their operating systems patched and updated, managing host firewall configuration, installing anti-virus on the systems. There is a class of security solutions, called Cloud Workload Security (CWS) solutions or Cloud Workload Protection Platforms (CWPP) that provide functionality to help customers tackle this.

Where the gap occurs is in the layer of the stack between physical infrastructure and the application. If you’re deploying an application in a public cloud environment securely, you have to do the following before installing anything in the hosts or putting data storage buckets (this is just a representative subset of what needs to be done):

1. Create accounts and virtual networks (e.g., VPC)
2. Create security groups, NACLs etc. to segment traffic
3. Define IAM users, groups, roles and permissions for the various services
4. Set security policies for ELBs, ALBs, CDNs, etc.
5. Create software-defined entities such as S3 buckets, EC2 instances or templates, RDS instances or templates, and set security policies for them

This is the layer of software-defined infrastructure that needs to be created before installing the operating system and application software components. While the public cloud provider gives you the security constructs such as security groups and VPCs and the ability to define security policies for S3 buckets and RDS instances, it is your responsibility to actually set up security the right way. The default settings often don’t reflect the security posture that you want to deploy.

It has now become enough of an issue that Gartner is carving out a separate category of solutions, called Cloud Infrastructure Security Posture Assessment (CISPA), that is distinct from cloud workload protection platforms.

According to a Gartner report:

“In private and public cloud-based environments, there is a set of surrounding control plane infrastructure services that are used to provision/deprovision,

configure and manage the workload. For example, identity and access management (IAM) services, network connectivity, network configuration and storage configuration. Several of the CWPP vendors in this MarketGuide have begun offering CISPA capabilities. In addition, an emerging set of vendors outside the scope of this research provide cloud infrastructure security posture assessment (CISPA) capabilities.”

It is this layer of tools and security compliance that most organizations fail to leverage effectively. Most of us would probably be shocked to see a list of all the misconfigurations and unknown security holes we’ve unwittingly created for ourselves. Part of this comes down to misunderstandings and even good old fashioned laziness. But in many respects managing all of the variables you need to make this CIS layer solid is prohibitively difficult without outside help.

Trying to brute force your way to a perfectly compliant system is a herculean task. It takes a dedicated third party service such as Dome9 Clarity for visualization and the Compliance Engine to make sense out of the chaos raging in most of our environments.

They call it shared security for a reason. Being able to see misconfigurations, understand best practices and act quickly to stay compliant are the keys to pulling your weight effectively in this model.

Good luck and stay safe!