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.
Shared Responsibility Varies by Provider and Service Type
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.
Defining the lines in a shared responsibility model
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):
- In the AWS Shared Security model, AWS claims responsibility for “protecting the hardware, software, networking, and facilities that run AWS Cloud services.”
- Microsoft Azure claims security ownership of “physical hosts, networks, and data centers.” Both AWS and Azure state that your retained security responsibilities depend upon which services you select.
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.
A vendor-agnostic look at shared responsibility
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.
Figure: A vendor-agnostic view of the division of responsibilities in the shared responsibility model
Your Share of Cloud Security Responsibilities
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:
- Information and Data: By retaining control over information and data, you maintain how and when your data is used. Your provider has zero visibility into your data, and all data access is yours to control by design.
- Application Logic and Code: Regardless of how you choose to spin up cloud resources, your proprietary applications are yours to secure and control throughout the entire application lifecycle. This includes securing your code repositories from malicious misuse or intrusion, application build testing throughout the development and integration process, ensuring secure production access, and maintaining security of any connected systems.
- Identity and Access: You are responsible for all facets of your identity and access management (IAM), including authentication and authorization mechanisms, single sign-on (SSO), multi-factor authentication (MFA), access keys, certificates, user creation processes, and password management.
- Platform and Resource Configuration: When you spin up cloud environments, you control the operating environment. How you maintain control over those environments varies based on whether your instances are server based or serverless. A server-based instance requires more hands-on control over security, including OS and application hardening, maintaining OS and application patches, etc. In essence, your server-based instances in the cloud behave similar to your physical servers, and function as an extension of your datacenter. For serverless resources, your provider’s control plane gives you access to the setup of your configuration, and you are responsible for knowing how to configure your instance in a secure manner.
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.
Understanding the Gray Areas of the Shared Responsibility Model
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:
- Identity and Directory Infrastructure: Whether you’re using OS-level identity directories like Microsoft Active Directory or LDAP on Linux, or you opt for a third-party identity directory solution, the security configuration and monitoring of that system is yours to control in an IaaS cloud implementation.
- Applications: Server-based cloud environments, much like on-premises hosts, are a blank slate for installing and maintaining applications and workloads. You may run PaaS applications on your cloud servers, in which case you might be relieved of some of the security burden. However, any application or workload you move from your data center to a server-based instance in the cloud is solely your responsibility to secure.
- Network Controls: Your provider only maintains the network that’s directly under their control. All networking above the virtualization layer—whether physical or infrastructure-as-code—requires your security configuration and monitoring.
- Operating System: With server-based instances, you get to choose your OS and patch levels. While this allows you greater flexibility, it also means greater responsibility when it comes to security. You’ll need to keep up with current vulnerabilities, security patches, and environment hardening exercises to keep your server-based cloud resources secured.
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.
Responsibilities Always Owned by Your Cloud Service Provider
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:
- The Virtualization Layer: By controlling the provisioning of physical resources through virtualization, providers ensure segmentation and isolation of CPU, GPU, storage and memory to protect your users, applications, and data. This layer of abstraction acts as both a gateway and a fence, allowing access to provisioned resources, and protecting against potential misuse or malicious intrusion, both from the user environments, down, and the physical layer, up.
- Physical Hosts, Network and Datacenter: Cloud vendors protect their hardware through a variety of both software and physical means. Large cloud providers like AWS and Azure protect their servers from physical intrusion and tampering through a variety of protocols, and they also ensure rapid failover and high availability with comprehensive, built-in backup, restore, and disaster recovery solutions.
The Shared Responsibility Model in Practice
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.
How the shared responsibility model impacts your developers
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.
Securing the DevOps pipeline
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.
Shared responsibility and configuration management
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.
Compliance management, threat management, and visibility into the cloud
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.
Shared Responsibility Model Next Steps
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.
Stay tuned next week for Part 2 of this two-part series, “Automating Your Share of the Shared Responsibility Model” 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.
The post Shared Responsibility Model Explained appeared first on Cybersecurity Insiders.
August 14, 2020 at 09:10AM
0 comments:
Post a Comment