It's important for both cloud service providers (CSPs) and cloud service customers (CSCs) to properly implement, operate, and audit their parts of the Shared Security Responsibility Model (SSRM). The SSRM clarifies the security obligations of the CSP (the cloud vendor) and the CSC (that's you). Getting this right is crucial for keeping your cloud environment secure.

Where did this come from?

This guidance comes from the CSA Cloud Controls Matrix v4.0.10, published on 2023-09-26 by the Cloud Security Alliance. You can download the full Cloud Controls Matrix here. The CCM provides a cybersecurity control framework for cloud computing, aligned to industry-accepted security standards, regulations, and control frameworks like ISO 27001/27002, ISACA COBIT, PCI, NIST, NERC CIP, and many others.

Who should care?

This control applies to:

• Cloud Security Managers responsible for defining and overseeing their organization's portion of the SSRM
• Cloud Engineers and Developers implementing security controls within their cloud environments
• DevOps Engineers building automated deployment pipelines that embed security
• Compliance Managers who need to ensure and document adherence to the SSRM
• IT Auditors tasked with assessing the implementation of the SSRM

What is the risk?

Failing to properly implement your part of the SSRM could lead to security gaps and unprotected attack surfaces in your cloud environment. This significantly increases the risk of:

• Data breaches due to misconfigured storage, inadequate access controls, unpatched vulnerabilities, etc.
• Compliance violations if regulated data is exposed or audit requirements aren't satisfied
• Service outages if critical resources are not properly protected from cyber attacks or operational errors
• Reputational damage and loss of customer trust after a public security incident

Diligently upholding your SSRM obligations helps mitigate these risks. While not a silver bullet, it provides a strong security foundation.

What's the care factor?

The consequences of SSRM failures can be severe - hefty fines, lawsuits, lost business. But the level of effort required is significant. You'll need to carefully assess your specific situation:

• Highly regulated industries like finance and healthcare must prioritize SSRM to avoid compliance issues.
• Organizations handling sensitive data should emphasize SSRM to prevent damaging breaches.
• Public-facing services that could be crippled by an attack should focus on SSRM to maintain availability.
• Early-stage startups with limited resources may need to balance SSRM against other business priorities.

Overall, SSRM should be a key consideration for most organizations operating in the cloud. Neglecting it is ill-advised.

When is it relevant?

Implementing the SSRM makes sense when:

• Initially migrating systems to the cloud
• Deploying new cloud workloads and applications
• Conducting major updates to existing cloud environments
• Undergoing a compliance audit or security assessment
• Responding to newly discovered threats or vulnerabilities

It's less relevant for:

• Non-production environments with dummy data
• Isolated dev/test systems not handling real information
• Legacy workloads that will soon be retired

What are the trade-offs?

Proper SSRM implementation requires:

• Significant time from security, development, and operations personnel
• Potential project delays to work through security requirements
• Additional tools and services to monitor and secure the environment
• Degraded performance if security controls are overly restrictive
• Frustrated developers if security excessively constrains their work

However, cutting corners is very risky. Failing an audit or experiencing a breach will be far more costly.

How to make it happen?

1. Review the SSRM to determine your organization's security obligations. The CSP is generally responsible for securing the underlying cloud infrastructure, while you handle things like data protection, access management, application security, etc.
2. Conduct a thorough risk assessment to identify the most significant threats to your cloud environment. Determine what data and systems need the highest levels of protection.
3. Define security policies aligned to the SSRM and your top risks. Cover access control, data handling, change management, logging, incident response, and other key domains.
4. Implement robust security controls to enforce your policies. This will likely include:
   • Strong authentication (MFA) and role-based access control (RBAC)
   • Encryption for data at-rest and in-transit
   • Secure network configuration (proper segmentation, firewalls, etc.)
   • Vulnerability scanning and timely patching
   • Comprehensive logging and monitoring
   • Automated security testing in the CI/CD pipeline
5. Leverage your cloud platform's native security services where possible to reduce friction.
6. Establish change management procedures to review security impacts before modifying the environment. Use infrastructure-as-code to maintain secure configurations.
7. Test controls thoroughly to verify they are operating as intended. Conduct penetration testing to identify any gaps.
8. Collect evidence of SSRM implementation for audit purposes. This could include policy documents, network diagrams, access reviews, patching records, penetration test results, etc.
9. Perform ongoing security monitoring to detect potential incidents. Have a tested incident response plan to promptly investigate and mitigate issues.
10. Regularly review and update your SSRM implementation as the threat landscape changes. Stay in close communication with your CSP.

What are some gotchas?

• Carefully evaluate the default security configurations of cloud services you use. They may be too permissive out of the box. For example, AWS S3 buckets are private by default, but can be inadvertently exposed with the wrong access policy.
• Understand the shared responsibility model of your specific cloud provider. The exact division of duties varies between CSPs.
• Confirm that your CSP maintains relevant compliance certifications for your industry, such as PCI DSS, HIPAA, SOC 2, etc. You'll still have compliance obligations, but the CSP should handle a significant portion.
• Restrict access to cloud management consoles and APIs. Attackers could wreak havoc with admin privileges. Use RBAC to limit permissions and require MFA.
• Many major cloud breaches are caused by misconfigurations, not sophisticated zero-days. Focus on the basics like enabling encryption, properly configuring security groups, rotating keys, patching quickly, etc.

What are the alternatives?

The core concept of a Shared Security Responsibility Model is not unique to the CSA CCM. Other frameworks address this too:

• NIST SP 800-53 has several controls related to external system services and supply chain risk management.
• ISO/IEC 27001 also has provisions for supplier relationships in Annex A.15.
• The PCI DSS requires service providers to clearly define security responsibilities in Requirement 12.8.

However, the CSA CCM is specifically tailored for cloud computing. It provides prescriptive guidance aligned to the predominant CSP models.

Explore further

• Read the CSA's Security Guidance for Critical Areas of Focus in Cloud Computing for additional context on the CCM
• Review your CSP's shared responsibility documentation, such as AWS, Azure, or Google Cloud
• Examine the NIST Cybersecurity Framework for an alternative approach to managing cyber risk
• Study the Center for Internet Security's Critical Security Controls for additional guidance on essential cyber hygiene

This CSA CCM control relates to several CIS Controls, including:

• [CIS Control 3](https://www.cisecurity.org/controls

?