Cloud service providers adhere to a shared security responsibility model, which means your security team maintains some responsibilities for security as you move applications, data, containers, and workloads to the cloud, while the provider takes some responsibility, but not all. 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 center model, you are responsible for security across your entire operating environment, including your applications, physical servers, user controls, and even physical building security. 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.
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.
The following diagram provides a high-level, vendor-agnostic view of a shared responsibility model based on concepts, rather than service level agreements. 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 system, 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.
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.
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.
Read Part 2 of this two-part series, “Shared Responsibility Model Automation: Automating your Share” to learn how you can gain better control of your public, hybrid and multi-cloud environments.
If you’re not subscribed to our blog, be sure to sign up now. And as always, if you’d like to discuss the needs of your specific environment, please don’t hesitate to contact us.