Breaking Down the Real Meaning of an XDR Solution
Read More This article dives into Understanding Network DLP, how it works, use cases
Want to stay ahead of threats in 2025? This research report is all you need to stay updated.
Cloud service providers adhere to a shared security responsibility model, which includes ensuring physical security of their data centers and infrastructure, while your security team maintains some responsibilities for security as you move applications, data, containers, and workloads to the cloud. Defining the line between your responsibilities and those of your providers is imperative for reducing the risk of introducing vulnerabilities into your public, hybrid, and multi-cloud environments.
In a traditional data centre model, you are responsible for security across your entire operating environment, including your applications, physical servers, user controls, and even physical security of the building. In a cloud environment, your provider offers valuable relief to your teams by taking on a share of many operational burdens, including security. In this shared responsibility model, security ownership must be clearly defined, with each party maintaining complete control over those assets, processes, and functions they own. By working together with your cloud provider and sharing portions of the security responsibilities, you can maintain a secure environment with less operational overhead.
Cloud service delivery models, including Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), play a crucial role in determining the shared responsibility model. Each model delineates the division of security responsibilities between the cloud provider and the customer differently.
In an IaaS model, the cloud provider is responsible for the underlying infrastructure, which includes the physical servers, networking, and data centres. The customer, on the other hand, is responsible for the operating system, applications, and data. This means that while the provider ensures the security of the physical infrastructure and virtualization layer, the customer must manage the security configuration of the operating system, applications, and data.
In a PaaS model, the provider takes on more responsibility by managing the underlying infrastructure and the platform itself. This includes the operating system and middleware. The customer is then responsible for the applications they deploy and the data they store. This model reduces the operational burden on the customer but still requires them to secure their applications and data.
In a SaaS model, the provider is responsible for the entire stack, including the application, platform, and infrastructure. The customer’s responsibility is primarily focused on data security and user access management. This model offers the highest level of convenience but still requires the customer to ensure proper data handling and access controls.
Understanding the cloud service delivery model is essential for determining the shared responsibility model. Customers must carefully review the service level agreement (SLA) and understand the security responsibilities of both the provider and the customer. By doing so, customers can ensure that they are meeting their security obligations, and that the provider is meeting theirs.
The key to a successful security implementation in a cloud environment is understanding where your provider’s responsibility ends, and where yours begins. The answer isn’t always clear-cut, and definitions of the shared responsibility security model can vary between service providers and can change based on whether you are using infrastructure-as-a-service (IaaS) or platform-as-a-service (Paas):
While the wording is similar, shared responsibility agreements leave much open for discussion and interpretation. But there are always some aspects of security that are clearly owned by the provider and others that you will always retain. For the services, applications, and controls between those ownership layers, security responsibilities vary by cloud provider and service type. In a multi-cloud environment, these variations in ownership introduce complexity and risk. Each environment, application, and service requires a unique approach for security assessment and monitoring. However, your overall security posture is defined by your weakest link. If you have a gap in coverage in any one system, you increase vulnerability across the entire stack and out to any connected systems.
In this whitepaper you will discover:
The following diagram provides a high-level, vendor-agnostic view of a shared responsibility model based on concepts, rather than service level agreements. This includes ensuring physical security of the data centers and infrastructure that support cloud services. When entering into a discussion with a cloud provider, security needs to be included upfront in the decision-making process regarding shared responsibilities. You can use this guide to inform your discussion and to understand your roles and responsibilities in securing your cloud implementation.
Whether in the data center, or using a server-based IaaS instance, serverless systems, or a PaaS cloud service, you are always responsible for securing what’s under your direct control, including:
Additionally, you maintain responsibility for securing everything in your organization that connects with the cloud, including your on-premises infrastructure stack and user devices, owned networks, and applications, and the communication layers that connect your users, both internal and external, to the cloud and to each other. You’ll also need to set up your own monitoring and alerting for security threats, incidents, and responses for those domains that remain under your control. These responsibilities are yours whether you are running on AWS, Azure, or any other public cloud provider’s systems.
Gain unmatched visibility across every cloud server and container with Fidelis Halo:
Based on whether you are running an IaaS or PaaS implementation, you may retain additional security responsibilities, or your provider may take some of that burden off your team. The line between your responsibility and those of your cloud vendor is dependent upon selected services and the terms of those services.
In the case of server-based instances, you often assume full responsibility of:
When you choose a serverless environment or PaaS solutions, you do alleviate some of the security burden. Serverless solutions provide a control plane for configuration, and you are responsible for configuring that service in a secure manner. For example, in a serverless environment, you may have the opportunity to choose an operating system (typically Microsoft or Linux), but your provider maintains responsibility of the OS patching and security management in that environment. Serverless environments typically provide some management of the physical implementation of your identity and directory infrastructure, applications, and network controls as well, but you are still responsible for properly configuring access management through the control plane.
While it may seem that you retain a significant share of security responsibilities, your provider does alleviate much of your burden. Cloud vendors maintain 100% of control over the security of:
When speaking of “shared responsibility,” it’s important to understand that you and your cloud provider never share responsibility for a single aspect of security operations. The areas of ownership you control are yours alone, and your provider does not dictate how you secure your systems. Likewise, you have no control over how the provider secures their portions of the application and infrastructure stack. You do, however, have the ability and right to access your cloud vendor’s audit reports to verify that their systems are secure and that they are adhering to your terms of service. Cloud providers publish these reports regularly and freely, and the most current reports are accessible at all times.
Cloud services offer convenient, automated environment provisioning, allowing developers and test groups to spin up servers through self-service processes. These environments, however beneficial for innovative potential, are often connected to your production assets and can pose significant security risks if not properly configured. While the cloud is inherently secure from the provider’s perspective, a secure cloud requires proper configuration and diligent access management. Gartner states the misconfiguration accounts for 99% of cloud security failures. For would-be hackers, cloud development and testing environments that are set up without enforcing proper security policies can become a gateway into your production systems or proprietary code storage. This means that identity and access management and environment configuration management must be closely managed, sometimes at the expense of unfettered convenience. Centralized, automated access management and policy-driven environment creation are critical for the success of your cloud security implementation.
Cloud applications, powered by an automated CI/CD pipeline and driven by a DevOps organization, accelerate the speed at which your business delivers new applications and features. Unfortunately, that also means your DevOps pipeline can inadvertently and rapidly introduce security vulnerabilities without proper consideration and management. In a shared responsibility model, you are responsible for securing your code and the tools you use to deliver applications to the cloud. The servers and serverless assets that make up your DevOps toolchain must be protected, including code repositories, Docker image registries, Jenkins orchestration tools, etc. Beyond securing your CI/CD pipeline, you can—and should—leverage CI/CD automation processes to shift security left, by integrating security into the code and making it part of the build. This idea of “shifting left” means automated testing against clearly defined security requirements, early and often in the development process, so that new vulnerabilities are caught and remediated before being merged into the larger code tree or introduced into a production service.
The speed and ease of configuring software-defined infrastructure opens your company up to new levels of agility and adaptability. However, the ability to reconfigure resources on the fly can also have instantaneous and broad-reaching consequences. The potential for misconfiguration can lead to security vulnerabilities. Your operations team needs to work closely with security to maintain policy-based control over how and when your cloud resources are provisioned. Your security teams are also accountable for monitoring resource management in the cloud for potential vulnerabilities. Through scripting, automation, and carefully planned self-service workflows, your configuration management and security teams can work together to give your company controlled, secure access to the cloud resources they need without becoming a bottleneck.
Regardless of where your security responsibilities end and your cloud provider’s responsibilities start, compliance with your organizational standards and required regulatory boards is your company’s responsibility. Centralized security orchestration, automation, and response allows you to collect and analyze data across your entire infrastructure, including your on-premises systems, public, hybrid and multi-cloud environments, and out to your edge and endpoints. With the right security platform in place, your teams gain deep visibility that allows you to analyze and respond to threats and maintain compliance, often without human involvement.
Ensuring the security of cloud environments requires adherence to a set of best practices. These practices help in maintaining a robust security posture and mitigating potential risks. Here are some essential cloud security best practices:
By following these best practices, customers can ensure that their cloud environments are secure and that they are meeting their security obligations. These practices not only help in protecting cloud resources but also in maintaining a strong security posture in the ever-evolving landscape of cloud security.
Any time your cloud provider takes on a portion of security responsibility, it becomes one less concern for your organization. Clearly defined shared responsibilities allow you to focus your efforts on your application delivery strategy without overburdening your teams with day-to-day operational concerns in the physical layer. A security platform that unifies and automates security controls from the data center and across each cloud simplifies security management and minimizes risk. Centralized control and configuration of the provider control plane, hosting, and orchestration for containers, applications, and workloads further improves coverage of your environment from end to end.
The shared responsibility model provides a working framework for cloud service providers to detail responsibility for an entire cloud environment, including the hardware, data, identity, workload, networks, networking, settings, etc.
This principle applies in the context of shared responsibility where global, locale or individual actors are assigned the same responsibility according to each function or capability defined by the Principle of optimal attribution of role or responsibility.
Jon Belanger is a seasoned Sr. Analyst in Threat Research with a passion for unraveling the intricate world of cybersecurity. Over the years, Jon has honed his skills through hands-on experience and a commitment to staying ahead of the ever-evolving threat landscape.
See Fidelis in action. Learn how our fast and scalable platforms provide full visibility, deep insights, and rapid response to help security teams across the World protect, detect, respond, and neutralize advanced cyber adversaries.