Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content.
You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Managing your cookies

Our website uses cookies. You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button.

Necessary cookies

These are essential for the user navigation and allow to give access to certain functionalities such as secured zones accesses. Without these cookies, it won’t be possible to provide the service.
Matomo on premise

Marketing cookies

These cookies are used to deliver advertisements more relevant for you, limit the number of times you see an advertisement; help measure the effectiveness of the advertising campaign; and understand people’s behavior after they view an advertisement.
Adobe Privacy policy | Marketo Privacy Policy | MRP Privacy Policy | AccountInsight Privacy Policy | Triblio Privacy Policy

Social media cookies

These cookies are used to measure the effectiveness of social media campaigns.
LinkedIn Policy

Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Skip to main content

The future of CSP’s security: shared fate or shared responsibility?

When we talk about cloud, the first things that come to mind are often: agile, flexible and scalable. But if security issues are not properly considered, they will soon overshadow all the benefits and become a major headache. To become security resilient, two areas must be considered: “security of the cloud” and “security in the cloud.”

An enterprise with its own data centers on-premises uses its own IT staff and employees to run and manage the IT infrastructure, applications and data. As a result, the enterprise is solely responsible for all security aspects. In contrast, an organization that migrates to a public cloud computing model will share some (but not all) of the responsibilities with the cloud service provider (CSP).

Each party shares responsibility for different aspects of the security. In this case, the cloud provider is responsible for ensuring the security of the cloud, while the customer takes care of security in the cloud. Data always falls within the customer’s responsibility, but the final shared responsibility model is dependent on the provider and the actual cloud model used (SaaS, PaaS or IaaS).

In simple terms, cloud migration requires customers to give up control of their physical infrastructure and some control over their data in exchange for the benefits of innovation enablement, improved costs, state-of-the-art security and scalability.

While public cloud is efficient for small and medium business, large organizations start analyzing the possibility of reversing the cloud migration to on-premises or private cloud. An IDC survey shows that security is one of the top three drivers of workload repatriation, which is an act of reversing the migration from a public cloud back to a local system. Some reports suggest that this is a growing market trend.

The shared responsibility model is a cloud security framework that dictates the security obligations of a cloud computing service provider and its customers to ensure accountability.With its role as a security framework, the shared responsibility model is one area that CSPs must pay close attention to, as customers rank it as one of the top reasons for workload repatriation.

Strictly delimiting responsibility between CSP and the customer is valuable and necessary. But with the evolution of legislation, global tensions, increasing demand for sovereignty and rapid changes to the security landscape, it is not enough for customers to acknowledge the boundary between them and the cloud providers. It is time for CSPs and customers to actually share responsibility and work as partners, rather than using a framework to simply split responsibilities. This concept was first pioneered in 2016 and enhanced in 2022. This new philosophy — an update to the shared responsibility model — is called “shared fate.”

Shared fate is about preparing a secure landing zone for the customer, guiding them through it, being clear and transparent about the security controls they can configure, offering guardrails and helping them with cyberinsurance. Shared fate is more than sharing responsibility; it’s a combination of building blocks that create a strong foundation for securing the business. These blocks provide:

Secure by Default config

Secure-by-default configurations:
Customers start from a high security baseline

Secure blueprints

Secure blueprints:
Products and services are secured-by-default, with actual configuration code

Secure policy hier

Secure policy hierarchies:
Automation to ensure configurations are distributed at all levels

Consistent availability of-advanced security features

Consistent availability of advanced security features

High assurance attestation of controls

High assurance attestation of controls:
Compliance support and attestation to obtain insurance coverage for workloads

You can read more about Google’s approach to shared fate here.

With or without making public announcements about their progress, CSPs have already taken steps toward a shared fate philosophy. According to the Cloud Security Alliance, since its Treacherous 12 and Pandemic 11 reports were released, traditional cloud security concerns under CSPs’ responsibility (like DDoS, shared technology vulnerabilities, cloud provider data loss and system vulnerabilities) have been excluded from the list.

However, there is only so much that CSPs can do on their end. With increasing amounts of applications, data and workloads, turning all security responsibility over to cloud providers is simply not something that customers should feel comfortable with. While CSPs continuously invest heavily in building state-of-the-art security, they cannot manage security concerns that are higher in the customer’s technology stack. As a result, we can expect CSPs to continue building their security stack either in-house or through acquisitions, with the aim of alleviating as many customer pain points as possible.

CSPs will also adhere to the shared fate philosophy because their goal is to support customers in any way possible, including intermediating an insurance contract for customer workloads if required. Also, when it comes to customer responsibility, managed security service providers must step in and support security-proactive companies that contract managed services for at least some aspects of security.

Share this article

About the author

Raul Salagean

Raul Salagean

Lead Global Portfolio Manager for Cloud Security

Raul has joined Atos in 2020 on the position of Global Portfolio Manager for Cyber Security Services, being end-to-end responsible for services developed in Cloud Security domain. He is currently Lead Global Portfolio Manager for Cloud Security domain and member of Atos Expert Community. He describes himself as focused, self-motivated and kaizen minded.

Follow or contact Raul