Modern businesses can benefit from the flexibility, scalability, efficiency, and innovation that cloud computing provides. But it also comes with difficulties and risk to security of its own. How can you protect your assets and data on the cloud? In the cloud environment, who is in charge of what?


These issues along with others are addressed by the shared responsibility framework. The cloud service provider (CSP) and client roles and duties for various components of the cloud environment are outlined in the shared responsibility model, which is a framework. Servers, networks, storage, and database servers are just a few examples of the cloud infrastructure and services that CSPs are in charge of protecting. Depending on the type of cloud service used, customers are in charge of protecting their operating systems, software, network configurations, and data and applications in the cloud. The shared responsibility concept seeks to stop security holes in the cloud and establish accountability, strengthening everyone’s security posture.


The shared responsibility concept is not perfect, though. There are numerous pitfalls that could undermine this strategy and put clients at risk for security breaches. These five pitfalls are listed along with advice on how to avoid them.



Pitfall 1: Misunderstanding Cloud Security


Misunderstanding cloud security is among the common issues with the shared responsibility approach. Some clients hold strong opinions about cloud security that are either overly optimistic or negative. For instance, some clients could believe that everything is taken care of in the cloud because it is so safe. They might believe that the CSP has taken care of everything and that they can unwind and take advantage of the cloud’s advantages without worrying about security. This is untrue because a lot of things, such data security, access control, and configuration settings, remain in the customer’s control. Depending solely on the CSP may result in security flaws or missed opportunities.


However, some clients might believe that the cloud is so unsafe that they are unable to use it. They could be concerned that it exposes them to greater dangers and weaknesses than their own data centers. They can also doubt the CSP’s capability or commitment to safeguarding their information and assets. This is also untrue because cloud security offers several benefits to users, like scalability, automation, resilience, intelligence, etc. The CSPs have a significant financial and reputational motivation to maintain a high level of security for their clients.


The truth lies therefore somewhere in the middle of these two extremes. Cloud security is neither a nightmare scenario nor a miracle recipe. It is a joint responsibility that necessitates collaboration and an awareness of each party’s responsibilities.


Pitfall 2: Over-delegation of Responsibility


Over-delegation of responsibility is another risk associated with the shared responsibility concept. When moving systems to the cloud, some clients might not completely understand what actually remains on their plate. They might disregard their own responsibilities since they think the CSP is in charge of everything. This poses a danger of compliance problems or violations.


Because they believe the CSP will take care of it for them, some customers, for instance, could believe they do not need to worry about patching or updating their software or applications in the cloud. But how they leverage cloud service models will determine this. They are still in charge of patching and updating their guest operating systems and applications that are running on top of the CSP’s infrastructure even if they use Infrastructure as a Service (IaaS). They are still in charge of patching and updating their application code that runs on top of the CSP’s platform even if they use Platform as a Service (PaaS). Although companies might not need to patch or update anything if they use Software as a Service (SaaS), they still need to set their preferences and settings in accordance with their security requirements.


Therefore, it is crucial to carefully study what the supplier has stated regarding their obligations and restrictions in their documents. Even though they may go into great depth, their explanations can be tedious and occasionally hazy. Key documents to check for include the following:


  • Service Level Agreement (SLA): This document outlines the performance and service levels that the supplier agrees to offer, as well as the corrective actions and consequences in the event 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 outlines the provider’s security policies and procedures, including how they safeguard their infrastructure, respond to incidents, and adhere to legal requirements, among other things.


Customers can prevent potential misconceptions and irrational expectations about what the supplier can and cannot do for them by carefully reading these agreements.



Pitfall 3: Capability vs. Responsibility Gap


The capability vs. responsibility gap is the third risk in the shared responsibility model. It’s possible that some clients lack the abilities, materials, or equipment necessary to carry out their duties in the cloud. They could not have the necessary knowledge, resources, or personnel to put in place efficient security measures for their data in the new cloud environment.


This might be an issue since they risk missing important vulnerabilities or threats while also failing to adhere to any relevant legal obligations or industry standards that could be present in their cloud environment.



Investing in hiring, training, or keeping qualified personnel who can manage their cloud security obligations efficiently is one method to close this gap.


Utilizing specialist tools or services offered by other CSPs or ISVs to improve their security capabilities in the cloud is another method to fill this gap. However, this makes it more difficult to determine who is in charge of what and requires teams to manage and keep an eye on yet another CSP.


Using third-party vendors or partners to assist with cloud security requirements is one of the most popular and secure strategies. The management of cloud-based platforms and IT infrastructure can be offloaded to a single vendor, simplifying security and management at the same time, by using managed service providers (MSPs) or managed security service providers (MSSPs) to outsource part or all security activities in the cloud.



Pitfall 4: Default Settings and Configurations


Using cloud services or application default settings and configurations without altering or reviewing them is a typical mistake under the shared responsibility paradigm. This could lead to security flaws and open up user systems to assaults.


For a variety of reasons, default settings and setups can be troublesome. They have the ability to turn off crucial security-related serviceIt is crucial to adjust the cloud services’ or applications’ default configurations and settings in accordance with your level of risk tolerance, your security needs, and industry standards. To properly manage and automate them, you should use the tools and services provided by your CSP or other parties as well as routinely monitor and update them to stay up with changes in your environment. s or turn on undesired features that use resources. They may also leave some options open or ambiguous, which may cause misunderstanding or inconsistent results.


For instance, some customers might decide not to setup multi-factor authentication (MFA) for their cloud accounts or resources because they believe it will be too time-consuming or unnecessary, leaving them more open to credential theft or compromise. Many users might not think about altering the default encryption keys or algorithms for their cloud-based data that is in transit or at rest. However, because these settings could not fulfill their own security standards or requirements, this could leave them more susceptible to data breaches or leaks. Additionally, they might be known to attackers or shared with other customers. Customers should utilize their own encryption methods or keys that are secure, compliant with their regulations, and unique.


Pitfall 5: Lack of Visibility and Accountability


Lack of visibility and accountability is the fifth point of failure in the shared responsibility paradigm. Some clients might not have enough control over their CSP’s actions or understanding of their cloud environment. They can lack knowledge about their cloud infrastructure, understanding of the services provided by their CSP, and documentation supporting their performance and compliance.


For instance, cloud users might not have a precise inventory of the servers, databases, and apps that they utilize on the cloud. It’s possible that they are unaware of what they have, where they are, who owns them, who uses them, how they are set up, protected, or functioning. They may become more prone to mistakes, wastage, and insecurities as a result.


Another illustration is the fact that certain clients might not have a clear audit trail of their cloud-based actions, including who did what, when, when, why, and how. They might not have logs, reports, or alerts to track and measure their actions and results, making them more prone to mishaps. They might also not adhere to certain standards and rules.


As a result, it’s critical to have a high level of accountability and visibility over your cloud environment. You ought to have:


  • You can use the resources supplied by your CSP (or other parties) to increase your awareness of and control over your cloud environment.
  • Methods and techniques for recording and reporting your activities and results
  • Effective ways and methods for you and your CSP to interact and work together



To learn more about cloud cybersecurity shared responsibility model, feel free to talk to us today or email us at for a demo.