Managing security risks throughout the entire supply chain is critical for any cloud service offering. The Shared Security Responsibility Model (SSRM) helps define the roles and responsibilities of all parties involved, from the cloud service provider to the customer. Properly documenting, implementing, and managing the SSRM across the supply chain helps ensure security obligations are met.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix here. The matrix provides a comprehensive set of controls that are designed to help organizations assess the security risks associated with cloud computing and to implement the necessary security measures. For more info on shared responsibility in the cloud, check out the AWS Shared Responsibility Model.

Who should care?

• Cloud service providers offering IaaS, PaaS, or SaaS who need to clearly define security responsibilities
• Customers consuming cloud services who need to understand their security obligations
• Compliance officers ensuring proper security measures are in place across the supply chain
• IT managers overseeing relationships with cloud service providers and third parties

What is the risk?

Without a well-defined and managed SSRM, there is a risk that security responsibilities could fall through the cracks, leading to vulnerabilities. If it's not clear whether the provider or the customer is responsible for a particular security control, it may not get implemented. This could enable data breaches, compliance violations, service disruptions, and reputational harm. While the SSRM doesn't eliminate these risks entirely, it significantly reduces their likelihood by ensuring all parties are aware of and executing their duties.

What's the care factor?

Cloud service providers should prioritize the SSRM as a foundational part of their security and compliance programs. Failing to implement it thoroughly could jeopardize customer trust and lead to lost business. Customers should care about the SSRM to avoid unknowingly taking on security responsibilities they aren't equipped to handle. Meeting compliance requirements is much more difficult without a solid SSRM. Overall, for any substantial cloud deployment, the SSRM is a must-have.

When is it relevant?

Documenting and managing the SSRM is relevant for virtually any cloud service, across IaaS, PaaS and SaaS models. The more third parties involved (e.g. a SaaS provider building on top of IaaS), the more important it becomes to hash out responsibilities. For simple, isolated, low-risk workloads, a basic high-level SSRM may suffice. But for enterprise deployments supporting production systems and sensitive data, a comprehensive SSRM is essential. It's less relevant for on-prem infrastructure managed entirely by the organization.

What are the trade offs?

Implementing the SSRM requires an investment of time and effort to hash out responsibilities across internal and external parties. It necessitates close collaboration with providers and partners. In some cases, customers may need to negotiate with providers to get them to take on certain responsibilities. Documenting the SSRM in detail, keeping it up to date, and disseminating it to all stakeholders adds overhead. However, this is more than offset by the risk reduction and smoother security operations enabled by the SSRM.

How to make it happen?

1. Review standard shared responsibility models published by providers like AWS, Azure, Google Cloud, etc. Use these as a starting point.
2. Work with your cloud provider(s) to clarify all security responsibilities in detail. Get specific about who handles what for each service in your cloud environment.
3. Document everything in a responsibility assignment matrix (e.g. a RACI chart). Specify whether the provider, customer, or a third party is Responsible, Accountable, Consulted, or Informed for each task.
4. Have all internal teams review the SSRM and confirm they understand and accept their responsibilities.
5. Incorporate the SSRM into vendor contracts and service level agreements (SLAs). Ensure it is legally binding.
6. Communicate the SSRM to all relevant personnel. Provide training as needed to ensure everyone knows their role.
7. Implement mechanisms to verify all parties are meeting their responsibilities. This may include self-assessments, audits, penetration tests, etc.
8. Review and update the SSRM at least annually or any time there are significant changes to the cloud environment.

What are some gotchas?

• Some cloud providers' standard SLAs may not fully address the SSRM. Additional negotiation may be required to get adequate specificity and commitments.
• The division of responsibilities can vary significantly across cloud service models (IaaS vs PaaS vs SaaS). A thorough SSRM needs to take these differences into account.
• As you engage more cloud services and providers, the number of SSRM relationships to manage increases quickly. Each one requires careful attention.
• Implementing an SSRM requires tight collaboration across internal teams, providers and partners. Any weak links in communication can lead to gaps.
• Over time, cloud environments tend to become more complex, so the SSRM must be continuously updated to stay current. You can't just set it and forget it.

What are the alternatives?

There aren't really any alternatives to the SSRM per se, as it's a fundamental requirement for using cloud securely. However, some organizations choose to use a standard SSRM template from a provider like AWS rather than developing a fully customized one. This can be a good choice for simple deployments. Ultimately though, any substantial cloud usage necessitates a tailored SSRM. Tools like AWS Config and Azure Policy can help automate management and enforcement of the SSRM.

Explore further

• CSA Cloud Controls Matrix
• AWS Shared Responsibility Model
• Azure shared responsibility in the cloud
• Google Cloud Shared responsibility
• Shared Responsibility Model Explained
• CIS Controls v8 #3: Data Protection and #18: Application Software Security