It is funny how little incidents can trigger a bright idea. Between different origins and accents, during customer discussions in Brisbane, Australia, there was a brief misunderstanding about whether in the phrase "Shared Fate" I had meant "fate" or "faith". My point was about Shared Fate, but it was a fortunate accident and made me further explore what Shared Faith might mean in the context of cloud security.
Much of the customer discussions focused on the critical workloads they operate with material effect in the real world, including - as I described elsewhere - the impact on food and power supply to millions, or the potential for environmental disasters should anything go wrong with their core SAP systems running in the cloud. At the same time, sharing more information about SAP's own secure cloud transformation journey and the positive reaction that got from security leaders at our customers, made it clear to me that we have to show greater transparency in how we operate in order to gain our customers' trust.
That is the core of Shared Faith.
The most familiar phrase when it comes to cloud security is 'Shared Responsibility'. In my opinion, this is best expressed in AWS's Shared Responsibility Model page, where they make a very clear distinction between what they are responsible for, and what is the responsibility of the customer. It makes it very clear what the responsibility of the cloud provider is:
The rest of the article then is explicit in outlining everything that the customer is responsible for, that is, the secure configuration of every service that the consumer of the cloud services decides to use. AWS offers security services that can help with that, but the decision to use them is up to their customers.
I like the clarity in this page. Maybe my only structural argument with it is that I would prefer it was called Separated Responsibility model, rather than Shared, but that is nitpicking. It also seems particularly appropriate for Infrastructure-as-a-Service (IaaS) cloud services, where the service is cloud primitives of compute, network and storage services, as well as load balancers, gateways, and databases. The cloud provider offers the ability to rent resources that customers - within acceptable use policy terms - can do with whatever they want.
While Shared Responsibility describes the relationship clearly, the question does come up whether each side is equally able to live up to their responsibilities. Many users of IaaS services do not necessarily have the skills in-house to configure cloud services securely, and different cloud providers have a varying set of secure defaults. Phil Venables and Anton Chuvakin from Google Cloud last year called on cloud service providers to work towards a more resilient model and "reimagine the shared responsibility model to better capture the full spirit of the relationship required for a true partnership to transform security in the cloud". They continue:
They manifest that through secure-by-default configurations, secure blueprints and secure policy hierarchies (guardrails and paved roads, if you like), the availability of security features and services to support cloud customers to operate more securely, and attestation of controls and insurance partnerships. The phrase immediately resonated with me, and I have used it myself both internally in the organization and externally with our customers to describe a better approach to cloud security to achieve effective outcomes. We depend on each other, both across SAP developer teams, central service teams and platform engineering teams, as well as our customers. If either of us fail, we all fail. This approach seems to fit better with Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) cloud services, and recognizes that cloud providers need to do more to support customers in their secure cloud transformation and to run more securely in the cloud.
However, it is time for the next stage in the evolution. As mentioned above, somewhat by accident we stumbled upon the term Shared Faith, but the more I think about it, the more I believe we need to evolve the model yet again.
Let's look at the difference in definition between "fate" and "faith". Fate implies we share the same destiny. Whatever happens, we are in the same boat together, condemned to each other. It also implies events beyond our control. It sounds inherently ominous, and for a partnership involving those in the public sector or under regulatory requirements in a critical industry, this may not meet the desired comfort level.
As Google Cloud or any other cloud provider, SAP "provide[s] independent review of our cloud services through compliance certifications, auditing content, regulatory compliance support, and configuration transparency." But we also find that many of our customers consider 3rd party audit attestations not enough to satisfy their concerns or contain enough information to conduct their own threat modeling. Documented assumptions and contractual obligations won't help much when you carry the risk for potential major real world disruptions depending how a cloud provider runs their operations. When you rely on a cloud provider to support critical services with significant impact on the economy, environment and society if they fail, such concerns are justifiable.
Faith, on the other hand, connotes complete trust or confidence in something or someone. Such trust and confidence can only be fostered by greater transparency. Such a trust relationship goes beyond secure defaults and security services that allow customers to run more securely. This is about proving to customers we as cloud provider run securely. We have to extend greater insight in how we operate to give customers the confidence that we meet our security obligations and can support them in managing their risk.
This evolution is aligned with the type of services and amount of control a customer retains or gives up in any cloud services scenario. In an IaaS situation, the customer still runs the systems and requires fewer guarantees on the underlying infrastructure provided by the cloud provider. Under Shared Fate, the customer is better supported by the cloud provider to run securely and might align with using more platform or even SaaS offerings. However, in cloud solutions such as SAP's - Enterprise SaaS and PaaS - the customer gives up all control apart from secure configuration of the application and user access, and relies entirely on the cloud provider to run their core systems securely.
Of course, customers give up that control willingly and move to the cloud in part to outsource this responsibility. But that doesn't change that these systems are critical to business operations with real-world impact and draw the attention of customers' security and risk teams. Naturally, that leads to increased demand from customers for greater transparency and trust.
One way that greater transparency and trust can be achieved is through the establishment of a Chief Trust Office. SAP's Chief Trust Officer Elena Kvochko talks about fostering trust in a digital world and establishing a trust organization in this recent blog. Aside from Security, Compliance and Privacy, the Trust Model she describes includes Transparency, involving making our security policy and process information available and accessible, engaging customers to understand their security needs and informing affected customers in the event of an incident. Her team runs SAP Trust Center and she also has a great podcast series, The Trust Corner.
This move to greater transparency is seen in the LogServ offering for RISE which facilitates secure storage and access to a customer's own OS, database, DNS, network and flow logs, and centralizes logs from all systems, applications, and Enterprise Cloud Services (ECS) services in use.
It is also reflected through our Customer Success Cyber Security Hubs, who support customers during the sales cycle and beyond when it comes to topics of security and secure transition to the cloud, and facilitate discussions between customer and SAP security leaders and executives.
Finally, it is seen through blogs like these, thought leadership and white papers, security research and contributions to governmental and supra-governmental policy and cooperation networks, conference talks, open source contributions, etc. from security professionals throughout SAP. Of course, SAP is not unique in that among cloud providers. I appreciate for instance the insights into Google Cloud's internal operations and thought leadership offered through the Cloud Security Podcast by Google, and the articles posted through their Office of the CISO.
We are aware, though, that the demand for transparency from our customers still exceeds our ability to meet it. We are running through several experiments to see where we can make further improvements and scale them operationally. We hope soon to be able to share more how we progress from Shared Fate to Shared Faith in our ongoing secure cloud transformation.
Much of the customer discussions focused on the critical workloads they operate with material effect in the real world, including - as I described elsewhere - the impact on food and power supply to millions, or the potential for environmental disasters should anything go wrong with their core SAP systems running in the cloud. At the same time, sharing more information about SAP's own secure cloud transformation journey and the positive reaction that got from security leaders at our customers, made it clear to me that we have to show greater transparency in how we operate in order to gain our customers' trust.
That is the core of Shared Faith.
Shared Responsibility
The most familiar phrase when it comes to cloud security is 'Shared Responsibility'. In my opinion, this is best expressed in AWS's Shared Responsibility Model page, where they make a very clear distinction between what they are responsible for, and what is the responsibility of the customer. It makes it very clear what the responsibility of the cloud provider is:
AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
The rest of the article then is explicit in outlining everything that the customer is responsible for, that is, the secure configuration of every service that the consumer of the cloud services decides to use. AWS offers security services that can help with that, but the decision to use them is up to their customers.
I like the clarity in this page. Maybe my only structural argument with it is that I would prefer it was called Separated Responsibility model, rather than Shared, but that is nitpicking. It also seems particularly appropriate for Infrastructure-as-a-Service (IaaS) cloud services, where the service is cloud primitives of compute, network and storage services, as well as load balancers, gateways, and databases. The cloud provider offers the ability to rent resources that customers - within acceptable use policy terms - can do with whatever they want.
Shared Fate
While Shared Responsibility describes the relationship clearly, the question does come up whether each side is equally able to live up to their responsibilities. Many users of IaaS services do not necessarily have the skills in-house to configure cloud services securely, and different cloud providers have a varying set of secure defaults. Phil Venables and Anton Chuvakin from Google Cloud last year called on cloud service providers to work towards a more resilient model and "reimagine the shared responsibility model to better capture the full spirit of the relationship required for a true partnership to transform security in the cloud". They continue:
... shared fate happens when a cloud provider and a client “work together as a team for a common goal and share a fate greater than the dollars that pass between them.” It’s a bigger-picture version of shared responsibility that encompasses it, but also transcends it. ...
Security shared fate is about preparing a secure landing zone for a customer, guiding them while there, being clear and transparent about the security controls they can configure, offering guardrails, and helping them with cyber-insurance.
They manifest that through secure-by-default configurations, secure blueprints and secure policy hierarchies (guardrails and paved roads, if you like), the availability of security features and services to support cloud customers to operate more securely, and attestation of controls and insurance partnerships. The phrase immediately resonated with me, and I have used it myself both internally in the organization and externally with our customers to describe a better approach to cloud security to achieve effective outcomes. We depend on each other, both across SAP developer teams, central service teams and platform engineering teams, as well as our customers. If either of us fail, we all fail. This approach seems to fit better with Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) cloud services, and recognizes that cloud providers need to do more to support customers in their secure cloud transformation and to run more securely in the cloud.
Shared Faith
However, it is time for the next stage in the evolution. As mentioned above, somewhat by accident we stumbled upon the term Shared Faith, but the more I think about it, the more I believe we need to evolve the model yet again.
Let's look at the difference in definition between "fate" and "faith". Fate implies we share the same destiny. Whatever happens, we are in the same boat together, condemned to each other. It also implies events beyond our control. It sounds inherently ominous, and for a partnership involving those in the public sector or under regulatory requirements in a critical industry, this may not meet the desired comfort level.
As Google Cloud or any other cloud provider, SAP "provide[s] independent review of our cloud services through compliance certifications, auditing content, regulatory compliance support, and configuration transparency." But we also find that many of our customers consider 3rd party audit attestations not enough to satisfy their concerns or contain enough information to conduct their own threat modeling. Documented assumptions and contractual obligations won't help much when you carry the risk for potential major real world disruptions depending how a cloud provider runs their operations. When you rely on a cloud provider to support critical services with significant impact on the economy, environment and society if they fail, such concerns are justifiable.
Faith, on the other hand, connotes complete trust or confidence in something or someone. Such trust and confidence can only be fostered by greater transparency. Such a trust relationship goes beyond secure defaults and security services that allow customers to run more securely. This is about proving to customers we as cloud provider run securely. We have to extend greater insight in how we operate to give customers the confidence that we meet our security obligations and can support them in managing their risk.
Loss of Control and Depth of Impact
This evolution is aligned with the type of services and amount of control a customer retains or gives up in any cloud services scenario. In an IaaS situation, the customer still runs the systems and requires fewer guarantees on the underlying infrastructure provided by the cloud provider. Under Shared Fate, the customer is better supported by the cloud provider to run securely and might align with using more platform or even SaaS offerings. However, in cloud solutions such as SAP's - Enterprise SaaS and PaaS - the customer gives up all control apart from secure configuration of the application and user access, and relies entirely on the cloud provider to run their core systems securely.
Table describing the evolution from Shared Responsibility to Shared Faith
Of course, customers give up that control willingly and move to the cloud in part to outsource this responsibility. But that doesn't change that these systems are critical to business operations with real-world impact and draw the attention of customers' security and risk teams. Naturally, that leads to increased demand from customers for greater transparency and trust.
Trust Through Transparency
One way that greater transparency and trust can be achieved is through the establishment of a Chief Trust Office. SAP's Chief Trust Officer Elena Kvochko talks about fostering trust in a digital world and establishing a trust organization in this recent blog. Aside from Security, Compliance and Privacy, the Trust Model she describes includes Transparency, involving making our security policy and process information available and accessible, engaging customers to understand their security needs and informing affected customers in the event of an incident. Her team runs SAP Trust Center and she also has a great podcast series, The Trust Corner.
This move to greater transparency is seen in the LogServ offering for RISE which facilitates secure storage and access to a customer's own OS, database, DNS, network and flow logs, and centralizes logs from all systems, applications, and Enterprise Cloud Services (ECS) services in use.
It is also reflected through our Customer Success Cyber Security Hubs, who support customers during the sales cycle and beyond when it comes to topics of security and secure transition to the cloud, and facilitate discussions between customer and SAP security leaders and executives.
Finally, it is seen through blogs like these, thought leadership and white papers, security research and contributions to governmental and supra-governmental policy and cooperation networks, conference talks, open source contributions, etc. from security professionals throughout SAP. Of course, SAP is not unique in that among cloud providers. I appreciate for instance the insights into Google Cloud's internal operations and thought leadership offered through the Cloud Security Podcast by Google, and the articles posted through their Office of the CISO.
We are aware, though, that the demand for transparency from our customers still exceeds our ability to meet it. We are running through several experiments to see where we can make further improvements and scale them operationally. We hope soon to be able to share more how we progress from Shared Fate to Shared Faith in our ongoing secure cloud transformation.
- SAP Managed Tags:
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
