2

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

 1 year ago
source link: https://venturebeat.com/security/cloud-security-where-do-csp-and-client-responsibilities-begin-and-end/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

Check out all the on-demand sessions from the Intelligent Security Summit 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. 

Want must read news straight to your inbox?
Sign up for VB Daily

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.” 

Event

Intelligent Security Summit On-Demand

Learn the critical role of AI & ML in cybersecurity and industry specific case studies. Watch on-demand sessions today.

Watch Here

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)
  • 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.”

VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK