In a world of complex supply chains and shared security responsibilities, clear guidance is essential. The Shared Security Responsibility Model (SSRM) Guidance provides critical information about how security responsibilities are divvied up across the supply chain. It's like a playbook that helps everyone understand their role in keeping things secure.

Where did this come from?

CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix here: https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4

The Cloud Security Alliance developed this control as part of their ongoing mission to promote secure cloud computing practices. It complements other guidance like the AWS Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/

Who should care?

• Cloud Service Providers (CSPs) who need to clearly communicate security responsibilities to customers
• Compliance officers ensuring their organization meets contractual and regulatory obligations
• Procurement teams evaluating potential cloud vendors and understanding security SLAs
• IT leaders migrating to the cloud who need to understand the security model

What is the risk?

Without clear SSRM guidance, there is a risk that important security controls fall through the cracks. If responsibilities are not well understood and documented:

• Vulnerabilities may not be identified and remediated in a timely manner
• Incident response may be delayed as parties debate who is responsible
• Compliance violations may occur if required controls are not implemented

While SSRM guidance alone cannot eliminate these risks entirely, it significantly reduces their likelihood and potential impact by establishing clear expectations.

What's the care factor?

For CSPs, providing clear SSRM guidance should be a top priority. In the event of a security incident, ambiguity around responsibilities could lead to reputational damage and loss of customer trust.

Compliance officers and IT leaders should also care deeply, as SSRM directly impacts their ability to meet security and compliance obligations. Misunderstandings in this area could lead to costly audits, fines, or worse.

When is it relevant?

SSRM guidance is most relevant when:

• Onboarding new cloud customers
• Updating contracts or service level agreements
• Launching new cloud services or features
• Responding to security incidents involving multiple parties

It may be less critical for very small, simple cloud deployments with few external dependencies. But for most real-world use cases, SSRM guidance is a must-have.

What are the trade-offs?

Developing and maintaining comprehensive SSRM guidance does require an upfront investment of time and resources by the CSP. It may also lengthen sales cycles somewhat as customers review the materials.

However, this is far outweighed by the long-term benefits of improved security posture, clearer compliance, and increased customer trust. It's an investment well worth making.

How to make it happen?

1. Assemble a cross-functional team including representation from security, compliance, legal, product, and customer success.
2. Review existing shared responsibility models from major CSPs and industry standards bodies as a starting point.
3. Analyze your specific service offerings and map out security responsibilities at each layer - e.g. hardware, virtualization, network, storage, platform, application.
4. Be specific and unambiguous about what the CSP is responsible for vs. the customer. Use clear language that a non-technical audience can understand.
5. Document processes for handling edge cases, such as vulnerability management or incident response when multiple parties are involved.
6. Have the SSRM guidance reviewed and approved by senior leadership, including CISO and legal counsel.
7. Publish SSRM guidance in a prominent, easily accessible location, such as Trust Center or Security portal.
8. Train sales, support and implementation teams on the guidance so they can communicate it effectively to customers.
9. Reference SSRM guidance in contracts, SLAs and onboarding materials. Make it a key part of the customer experience.
10. Review and update SSRM guidance regularly to account for new service offerings, technologies and threat vectors.

What are some gotchas?

• Ensure the team developing SSRM guidance has appropriate expertise across security, compliance and product domains. Lack of key stakeholder input can lead to gaps.
• Watch out for ambiguous language that could be interpreted differently by the CSP vs customer, e.g. "reasonable security measures". Be as specific as possible.
• Avoid the temptation to claim the CSP has no responsibility for security. Even for customer-controlled layers like application code, the CSP likely still has obligations around the underlying infrastructure. Be accurate and balanced.
• Manage version control carefully as SSRM guidance evolves. Customers should always know what version they are referencing.

What are the alternatives?

There is really no alternative to providing some form of SSRM guidance. Lack of clarity around security responsibilities is simply not tenable in today's cloud environment.

Some smaller CSPs may choose to adopt the shared responsibility model of a major CSP like AWS or Azure rather than developing their own from scratch. This can be a reasonable approach, but should still be customized to the specifics of your service.

Explore further

• CSA Cloud Controls Matrix: https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4
• AWS Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/
• Microsoft Azure Shared Responsibility: https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• Google Cloud Shared Responsibility Model: https://cloud.google.com/security/shared-responsibility

This control aligns closely with the Communications and Control (CC) category in the CIS Controls framework, emphasizing the importance of clear communication around roles and responsibilities.

‍