Shared Responsibility, Roles & Responsibilities

With migrations to the cloud now becoming a norm rather than a novelty, it’s crucial for organizations to understand the underpinning responsibility as tenants of the public cloud. One of the misconceptions about moving to the cloud is that it relieves the customer of several responsibilities pertaining to their IT infrastructure—including their cybersecurity responsibilities. This needs clarification.

Cloud security is actually a shared responsibility. Meaning, there are components of the cloud whose security responsibilities are in the hands of the cloud service provider (CSP) and other facets whose responsibilities remain with the customer.

Why cloud security is a shared responsibility

Although it might seem to run counter to the spirit of cloud computing, treating cloud security as a shared responsibility actually benefits both the CSPs and the customers. In fact, it benefits customers in a big way, and once you’ve seen that from the eyes of a cloud customer, you would likely not want it any other way.

When you strip away all the mystique surrounding cloud computing, “clouds” are really just made up of datacenters—facilities staffed by people whose backgrounds you have zero knowledge of, but trust nonetheless. That’s something you should be concerned with because the 2017 Cost of Cyber Crime Study revealed that 40% of companies surveyed experienced attacks from malicious insiders. In other words, there’s a pretty good chance a cloud engineer could mess with the digital assets you entrust with your CSP.

By following a shared responsibility model for cloud security, you can actually reduce unauthorized access to your most prized digital assets (i.e. your data and applications) from within your CSP’s organization. This, in turn, can mitigate the risk of an insider attack from within your CSP or even an external attack that might take advantage of loopholes in your CSP’s security.

What does the shared responsibility model look like in terms of cybersecurity

A shared responsibility model for cloud security means the CSP is responsible for the security of the cloud. In other words, your CSP is responsible for securing assets such as:

  • the underlying hardware and assets
  • their global or regional infrastructure footprint
  • the hypervisors on which your compute instances are nested
  • the physical network, and physical security

In turn, the customer, as they utilize the infrastructure-as-a-service as it’s provisioned to them, is responsible for the security in the cloud. So this means, customers are expected to secure, among others:

  • their own data, including what they have within their organization and what they’re sharing with customers and business partners
  • the client platforms
  • the applications
  • the identity and access management they provide to their users within the organization.

In addition, customers are responsible for making sure that operating system, network, and firewall settings are configured for optimal security. They’re also responsible for their encryption mechanisms, including client-side encryption, server-side encryption, and, of course, network-side traffic encryption.

Making sure customers fully understand the scope of their responsibility, as to what components of the cloud they’re expected to secure, is critical. It will help them determine exactly what controls, mechanisms, and frameworks they need to employ to meet regulatory compliance and corporate security objectives without deviating from business goals, slowing business growth, or hindering innovation.

Who’s responsible for security?

When it’s all said and done, everyone is responsible for security—C-Suite executives, managers, IT staff, DevOps, and other employees—but the key to encouraging everyone to do their part is identifying where security initiatives best intersect with business requirements and operations. Usually, security initiatives are perceived to hinder business growth or even business continuity, but the opposite is actually true.

Let’s consider application delivery, for example. Oftentimes, a developer is expected to produce an application at a very agile pace and high velocity. Due to compliance requirements and more stringent corporate security policies, that developer also is now asked to implement proper security controls and frameworks. These additional steps may slow down the development process if done up front—a complication that can be disadvantageous to the developer or DevOps practitioner who also is likely under pressure to hit a target release date.

The way to make this work is to introduce security early on in the funnel, in the CI/CD pipeline. In this manner, security becomes an adjunct component of the development process. In the long run, it’s going to be much easier for the developer to maintain a security-conscious mindset and incorporate security while building the application instead of building the application and then augmenting security as an afterthought.

This concept can be applied to all other members of your organization. By making each member embrace a security-first mindset, you will be making it easier for them to view security as an accelerator of processes instead of a roadblock. Embracing a culture of proper security hygiene, and best practices will nourish a more efficient security posture and mitigate risk.

How to build your company’s shared responsibility model

This really comes down to understanding, again, where the intersect of these two different components, i.e. security and business processes, lies. Lately, we’re starting to see changes wherein developers and DevOps teams are not only implementing but also recommending how security should be implemented in the organization.

Before, you would normally have a CISO who would stipulate, based on best practices and defined regulatory frameworks, how a particular security control would be implemented. Deviating from that would be a non-starter. Today, however, decision makers are increasingly consulting with DevOps teams, system admins, and security analysts, because those teams understand proper tool orchestration can streamline and scale the business.

This consultative approach is an ideal way of building your company’s shared responsibility model because it enables key decision makers to make informed decisions based on inputs from people who have a better grasp of the depth and breadth of foundational elements and methodologies of security. Don’t let your cloud security fall on the shoulders of one entity. Understand, build out, implement and maintain your shared responsibility model with your CSP, team members and employees to ensure your company has the best security posture to drive momentum for business growth.

Resource Center

More security resources at your fingertips.

Practical Content for Security, DevOps, & IT Professionals