Cloud computing offers many advantages for modern businesses, such as flexibility, scalability, efficiency, and innovation. But it also poses its own challenges and security risks.
How can you secure your data and assets in the cloud? Who is in charge of what in the cloud environment?
The shared responsibility model helps address these questions and more. The shared responsibility model is a framework that defines the security and compliance roles and responsibilities of cloud service providers (CSPs) and customers for different components of the cloud environment. CSPs are responsible for securing the cloud infrastructure and services, such as servers, networks, storage, and databases.
Customers are responsible for securing their data and applications in the cloud, as well as their operating systems, software, and network configurations, depending on the type of cloud service they use. The shared responsibility model aims to prevent cloud security gaps and ensure accountability resulting in a stronger security posture for all parties.
However, the shared responsibility model is not foolproof. There are many pitfalls that can compromise this model and expose customers to security threats. Here are five of these pitfalls and how to avoid them.
Pitfall 1: Misunderstanding Cloud Security
One of the common difficulties regarding the shared responsibility model is misunderstanding cloud security. Some customers have extreme views on cloud security, either too optimistic or too pessimistic. For example, some customers may think that the cloud is so secure that they have nothing left to do. They may assume that the CSP has done it all and that they can relax and enjoy the benefits of the cloud without worrying about security.
This is not true, as there are many aspects that remain in the customer’s domain, such as data protection, access management, configuration settings. Relying on the CSP alone can lead to security gaps or missed opportunities.
On the other hand, some customers may think that the cloud is so insecure that they can’t use it. They may fear that it exposes them to more threats and vulnerabilities than their own data centers. They may also distrust the CSP’s ability or willingness to protect their data and assets. This is also not true, as there are many advantages of cloud security that customers can leverage, such as scalability, automation, resilience, intelligence, etc. The CSPs have a strong incentive to maintain a high level of security for their customers, as their reputation and revenue depend on it.
So, the truth is somewhere in between these two extremes. Cloud security is neither a magic formula nor a nightmare. It is a shared responsibility that requires both parties to work together and understand their roles and obligations.
Cloud Security Myths vs. Facts | |
|
The CSP is liable for any security breach or data loss in the cloud.
| The CSP is only liable for breaches or losses that result from their own negligence or misconduct. The customer is still responsible for complying with laws and regulations, securing their own data and applications, and reporting any incidents or issues.
|
| The customer has no control or visibility over their data and assets in the cloud. | The customer has full ownership and control over their data and assets in the cloud. They can choose where to store their data, how to encrypt it, who can access it, how to monitor it, etc. They can also use tools and services provided by the CSP or third parties to enhance the visibility and auditability of their cloud environment.
|
| The customer can use the same security tools and practices in the cloud as they do on-premises.
| The customer may need to adapt or adopt new security tools and practices in the cloud to match the different characteristics and challenges of cloud computing. For example, they may need to use more automation and orchestration tools to manage their security configurations across multiple cloud services and regions. They may also need to use more identity-based and data-centric security approaches to protect their data and assets in a dynamic and distributed cloud environment.
|
Pitfall 2: Over-Delegation of Responsibility
Another hazard in the shared responsibility model is over-delegation of responsibility. Some customers may not fully understand what really remains on their plate when they move systems to the cloud. They may make the assumption that the CSP is responsible for everything and do not pay attention to their own obligations. This can be risky and result in compliance issues or breaches.
For example, some customers may think that they do not need to worry about patching or updating their software or applications in the cloud because they assume that the CSP will do it for them. However, this depends on what type of cloud service model they use. If they use Infrastructure as a Service (IaaS), they are still responsible for patching and updating their guest operating systems and applications running on top of the CSP’s infrastructure. If they use Platform as a Service (PaaS), they are still responsible for patching and updating their application code running on top of the CSP’s platform. If they use Software as a Service (SaaS), they may not need to patch or update anything, but they still need to configure their settings and preferences according to their security requirement.
Therefore, it is important to read carefully what the provider has said in their documentation about their responsibilities and limitations. They may say it in detail, but it can be exhausting and sometimes not very clear. Some of the key documents to look for are:
- Service Level Agreement (SLA): This document defines the level of service and performance that the provider guarantees to deliver, as well as the remedies and penalties in case of failure.
- Terms of Service (TOS): This document defines the legal terms and conditions of using the provider’s service, including the rights and obligations of both parties, the acceptable use policy, the privacy policy, etc.
- Security Policy: This document defines the provider’s security practices and standards, including how they protect their infrastructure, how they handle incidents, how they comply with regulations, etc.
By reviewing these documents carefully, customers can avoid potential misunderstandings and unrealistic expectations about what the provider can or cannot do for them.
Pitfall 3: Capability vs. Responsibility Gap
A third risk in the shared responsibility model is the capability vs. responsibility gap. Some customers may not have the skills, resources, or tools to fulfill their responsibilities in the cloud. They may lack the expertise, staff, or budget to implement effective security measures for their data within the new cloud environment.
This can be problematic since they could miss critical vulnerabilities or threats while failing to comply with applicable regulatory requirements or industry standards present in their cloud environment.
One way to address this gap is to invest in training, hiring, or retaining skilled staff who can handle their cloud security responsibilities effectively.
Another way to address this gap is to use specialized tools or services provided by independent software vendors (ISVs) or other CSPs to enhance their security capabilities in the cloud. However, this can further complicate who is responsible for what and forces teams to manage and monitor yet another CSP.
One of the most popular, and secure, methods is to leverage third-party vendors or partners to help with cloud security needs. For example, utilizing a managed service providers (MSPs) or managed security service providers (MSSPs) to outsource some or all security tasks in the cloud helps offload the management of cloud-based platforms and IT infrastructure to a single vendor, simplifying security and management at once.
Pitfall 4: Default Settings and Configurations
A common mistake in the shared responsibility model is using default settings and configurations for cloud services or applications without changing or reviewing them. This can create security vulnerabilities and expose user systems to attacks.
Default settings and configurations can be problematic for several reasons. They can enable unwanted features that consume resources or disable important services that provide security. They can also leave some options open or unclear, resulting in confusion or inconsistency.
For example, some customers may not enable multi-factor authentication (MFA) for their accounts or resources in the cloud, because they think that it is too cumbersome or unnecessary, making them more susceptible to credential theft or compromise. Many users may not consider changing default encryption keys or algorithms for their data in transit or at rest in the cloud. However, this can make them more vulnerable to data breaches or leaks, because these defaults may not meet their specific security requirements or standards. They may also be shared with other customers or known to attackers. Customers should use their own encryption keys or algorithms that are unique, strong, and compliant with their policies.
It is important to customize the default settings and configurations of your cloud services or applications according to your risk acceptance level, security requirements, and best practices. You should also monitor and update them regularly to keep up with changes in your environment and use the tools and services offered by your CSP or third parties to help you manage and automate them effectively.
Pitfall 5: Lack of Visibility and Accountability
A fifth breakpoint in the shared responsibility model is lack of visibility and accountability. Some customers may lack insight into their cloud environment or enough oversight of their CSP’s actions. They may not know what is happening in their cloud environment, what their CSP is doing for them, or have enough documented evidence to prove their compliance and performance.
For example, cloud users may not have a clear inventory of their cloud-based assets such as servers, databases, and applications. They may not know what they have, where they are, who owns them, who uses them, how they are configured, how they are protected, or how they are performing. This can make them more prone to errors, waste, and insecurities.
Another example is some customers may not have a clear audit trail of their activities in the cloud, such as who did what, when, where, why, and how. They may not have logs, reports, or alerts to monitor and measure their actions and outcomes, making them more vulnerable to incidents and may also fail to comply with some regulations and standards.
Therefore, it is important to have a high level of visibility and accountability for your cloud environment and your CSP’s actions. You should also have:
- Tools and services provided by your CSP (or third parties) to help you gain more insight and oversight over your cloud environment
- Processes and procedures to document and report your activities and outcomes
- Mechanisms and channels to communicate and collaborate with your CSP effectively
What’s Next?
The shared responsibility model is a key concept for understanding cloud security and defining who is responsible for what in a cloud environment. It helps both CSPs and customers to prevent gaps in security and ensures accountability across the cloud and customer environments. By avoiding these pitfalls, you can improve your cloud security posture and performance, while still enjoying the benefits from cloud computing. Be sure to watch our full Cybersecurity Q&A on Why Adopt the Shared Responsibility Model in Your SecOps.
Author A.N. Ananth is Chief Strategy Officer for Netsurion. Read more Netsurion guest blogs here. Regularly contributed guest blogs are part of MSSP Alert’s sponsorship program.
