Skip to main content

Cloud security: Where do CSP and client responsibilities begin and end?

cloud lock security wavebreakmedia shutterstock
Image Credit: Shutterstock

Join us in Atlanta on April 10th and explore the landscape of security workforce. We will explore the vision, benefits, and use cases of AI for security teams. Request an invite here.


When it comes to cloud security, the question of who is responsible for what — the host or the hostee — can sometimes be a bit hazy. 

What are the obligations of the cloud service provider (CSP)? Where is culpability delineated? And is there overlap or a gray area? 

With the cost of a data breach at an all-time high of $4.4 million, these questions are top-of-mind for CISOs. 

As training and certification nonprofit (ISC)2 explains, in the early days of cloud computing, many “unaware executives became enamored with the idea that they would no longer be responsible for any of the ‘headaches’ associated with an on-premises data center.” 

VB Event

The AI Impact Tour – Atlanta

Continuing our tour, we’re headed to Atlanta for the AI Impact Tour stop on April 10th. This exclusive, invite-only event, in partnership with Microsoft, will feature discussions on how generative AI is transforming the security workforce. Space is limited, so request an invite today.
Request an invite

Still, “the shifting of certain responsibilities does not also mean the shifting of accountability,” the nonprofit cautions.

So how can organizations be sure about their responsibilities and those of their providers (and those that are shared)? Here, industry experts break it down. 

Understanding the shared security model

All of the major public clouds — such as AWS, Microsoft Azure, Oracle Cloud and IBM Cloud — observe what’s known as a “shared security model.” 

This, according to (ISC)2, means that an organization is responsible for security “in” the cloud and CSPs are responsible for ensuring the security “of” the cloud. These responsibilities vary based on software-as-a-service (SaaS), platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS) deployment. 

With IaaS, the hardware responsibility becomes diminished for the cloud customer, according to (ISC)2. Similar responsibility shifts are true of PaaS and SaaS models. 

“These models keep the customer off the upgrade treadmill, leveraging the expertise of the cloud provider,” according to the nonprofit. 

Still, the practical application is “where things can get tricky,” (ISC)2 cautions. Without expertise, executives can be “lulled” into the notion that a provider solves all of their cybersecurity problems. 

The responsibility ‘nuances’ of cloud security

Indeed, there are “nuances” of split responsibility, according to Gartner VP analyst Patrick Hevesi. He and colleague Gartner senior director analyst Charlie Winckless define 10 areas of cloud responsibility: 

  • Business continuity
  • Identity and access management (IAM)
  • Data
  • Application
  • Application API
  • Workload
  • Virtual network
  • Service orchestration
  • Virtualization/cloud infrastructure
  • Physical 

Naturally, with IaaS, the cloud provider is responsible for virtualization/cloud infrastructure and physical facets, Hevesi explained. PaaS providers are responsible for the same, in addition to virtual network and service orchestration. They share workload responsibilities with the client. 

The responsibility of SaaS providers ramps up; they are responsible for workload, and share responsibility when it comes to the application API and application areas. 

“There’s a lot more work on them, less for you, but less visibility, too,” said Hevesi. 

And, “in the end, the data line is always the customer’s responsibility,” said Hevesi. As are identity and access management and business continuity, he pointed out. 

‘Shared fate’ friendlier than it sounds

Some providers, though — Google Cloud for example — observe what’s known as a “shared fate approach.”

According to Google Cloud CISO Phil Venables, this means being “active partners” as organizations deploy securely on the platform, “not delineators of where our responsibility ends.” The methodology was introduced into Google’s IT operations in 2016. 

Shared fate centers around customer needs, he said; instead of pushing responsibility to customers who may not have the expertise to properly manage it, the provider uses its expertise to help them be more secure in the cloud.

For example, Google Cloud offers security foundations discussing top security concerns and recommendations, deployable blueprints and architecture framework best practices to help meet policy, regulatory and business objectives, he pointed out.

“Of course, there will always be some responsibility on the customer for their security, as no cloud provider can claim accountability for 100% of an organization’s security or activity in the cloud,” said Venables. 

Cloud customers must always undertake certain tasks and activities focused on security — defined by their workloads, their industry and their regulatory framework and location. 

“The difference with shared fate is that the cloud provider plays a significantly more active role in the customer’s security,” said Venables. This is “to the point where, if something were to go wrong, the cloud provider would be heavily invested and can better support the customer through that journey.”

Critical cloud security tactics

For cloud security, a cloud native application protection platform (CNAPP) is critical, said Hevesi. This category was defined by Gartner and involves integrating and centralizing all security functions into a single user interface. 

A cloud access security broker (CASB) is also critical, he said. Gartner defines these as enforcement points placed between users and providers “to combine and interject enterprise security policies as the cloud-based resources are accessed.” 

This method consolidates multiple types of security policy enforcement. Examples include authentication, single sign-on, authorization, credential mapping, device profiling, encryption, tokenization, logging, alerting, malware and detection. 

Ultimately, processes within an organization have to come into play, said Hevesi. This means understanding and changing them when needed. It could also involve training architects who understand risk assessment. 

Hevesi also advised that organizations establish a proof of concept with providers. “Don’t rely on vendor demos alone,” he said. 

The right technical expertise

(ISC)2 agrees that responsibilities surrounding cloud security “can be overwhelming to an untrained individual.” 

Cloud security professionals must have a span of knowledge in IaaS, PaaS and SaaS, the organization advises. Platform-specific training and vendor-neutral or multi-vendor training is available. 

And, a CISO must have the technical know-how and ability to take a strategic view of cloud security. They must understand risks and develop strategies for protection and mitigation. 

Ultimately, IT and security leaders should ask themselves, “Is our security team cloud-ready?”

Because, ultimately, (ISC)2 says, “this question could mean the difference between security success and failure in cloud implementation.”

VB Daily - get the latest in your inbox

Thanks for subscribing. Check out more VB newsletters here.

An error occured.