The ongoing trend for cloud adoption exposes businesses to multiple cloud security challenges. Learn how the shared responsibility model can help.
Enterprises actively adopt new digital technologies to rethink their operations following modern-time demands. Among the most widely adopted digital transformations are moving on-premises workloads and infrastructures to clouds. Cloud services satisfy ongoing business demands for easily deployable and rapidly scalable compute and network resources. However, they also rise a set of cloud security challenges and require reconsidering traditional approaches to security.
NIST defines cloud computing as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction (p. 2). Cloud computing involves the following characteristics:
On-demand self-service – users can provide computing services and capabilities of their clouds on their own.
Broad network access – all cloud services are available on any device, including mobile.
Resource pooling – multi-tenant model enables providers to serve multiple users.
Rapid elasticity – users can access, contract, or expand resources as quickly as they are used or freed.
Measured service – services are charged according to users’ needs.
All these characteristics help cloud providers to quickly serve their networks and provide users with multiple capabilities. However, they also rise a set of security challenges that often contribute to the vulnerability of users’ cloud-based assets.
Moving to the cloud, organizations often “lift and shift” their on-premise workloads and infrastructures with a little refactoring. However, it is impossible to migrate to the cloud by using only the legacy security philosophy and tools. It is because the cloud environment requires rethinking all security processes and generating new approaches to security.
The cloud environment changes extremely fast. It occurs due to streamlined provisioning processes and on-demand resources. This velocity of change weakens the security controls and existing security management so much that traditional security tools often cannot handle this “chaos.”
The reality of modern virtual instances is that they spin up as quickly as torn down. With the adoption of cloud environments, organizations lost a clear understanding of the boundaries of their workloads, networks, and responsibilities. So, the traditional perimeter-based security tools are not effective anymore as the perimeter has disappeared.
Even a simple cloud-based project creates enough security and compliance challenges. Let alone the multi-cloud or hybrid deployments that contribute to even bigger cloud complexity. In conditions where multiple cloud entities, event logs, configuration files, and networks exist, analyzing security incidents by using legacy data security tools is a complicated or sometimes an impossible task.
Cloud providers are responsible for maintaining and protecting the cloud platforms up to a certain point. Customers, in contrast, have less visibility and control over securing their cloud infrastructure and networks than they had in their on-premises environments. Furthermore, organizations are often hardly aware of the most acute issues and needs of their cloud-based networks and systems.
The lack of awareness often leads to multiple misconceptions that organizations have when moving to the cloud. Here we provide the common mistakes that organizations make when migrating their on-premises assets and infrastructure to the cloud.
Many organizations adopt cloud environments based on past notions and experiences with traditional software models. For instance, migrating Microsoft Exchange to the cloud is often incorrectly assumed as only requiring the integration of an on-premises Active Directory for user information and a configuration of spam filtering and other mail flow in cloud service. Organizations often assume that their existing on-premises security measures such as firewall configuration, intrusion prevention, and behavior analytics platforms, will be provided by the cloud vendor. It is the organization’s responsibility to install and keep up these security measures even if they used a cloud-based environment for their assets.
Enterprises that adopt cloud services should gain experience not only as part of their initial setup but also during the ongoing maintenance process. Unfortunately, it rarely occurs in practice. Many organizations believe that once service settings are configured, the ongoing maintenance will require less attention. This assumption is one of the most common reasons why companies have difficulties ensuring security for their cloud-based data.
As part of the initial cloud service adoption, organizations together with their cloud service providers must define key configurations and maintenance processes for the service. Among other things, they should define specific security requirements, such as complexity and rotation of credentials; privilege settings for users and administrators; users’ access to applications; administrators’ hierarchy, etc. Although organizations should regularly check for the state of these configurations, they often drift away from them to focus on supporting the overall business. Some enterprises defer configuration checks to audits. However, more commonly, they simply wait to react to security incidents or other failures to apply corrective actions. Both approaches lead to configuration drifts which make organizations vulnerable to security incidents.
The above challenges and misconceptions support the idea that security is one of the greatest concerns of the cloud environment. So both, cloud providers and their customers should properly bear their part of the burden and ensure security in the cloud. To define the borders of responsibility for securing data in clouds, a shared responsibility model was articulated.
The shared responsibility model outlines the provider’s responsibility for maintaining a secure and continuously available service and the organization’s duty to ensure the secure use of the service. There are two main approaches for defining the shared responsibility model in the cloud security context. These approaches demonstrate the best practices of top cloud service providers such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and IBM Cloud.
Security OF the Cloud vs. Security IN the Cloud
The first approach conveys how the cloud provider is responsible for managing the security of the cloud while the customer is responsible for securing what is in the cloud. Such differentiation of the shared responsibility model pertains to AWS and includes the following:
To maintain the Security of the Cloud, cloud providers are responsible for protecting the infrastructure that runs services offered in the cloud. This infrastructure involves software, hardware, networking, and facilities.
Security in the Cloud is the organization’s responsibility which is determined by the services that the organization selects. This, in turn, defines the amount of configuration work that must be performed. Configuration usually involves security controls for the guest operating system (including updates and security patches), application software or utilities installed by the customer, as well as network security management tools provided by the cloud vendor.
FIGURE 1. (Source: AWS Shared Responsibility Model)
Besides the IT environments, the shared responsibility model also involves controls such as management, operation, and verification. Organizations can inherit the operating controls from their cloud providers, share responsibility for maintaining some of them and be fully responsible for specific controls. Here are examples of shared responsibility regarding controls.
Inherited Controls – physical and environmental controls that the organization inherits from its cloud provider.
Shared Controls – the cloud provider and the customer are responsible for certain aspects of the control. Examples of shared controls may include configuration management, patch management, training & awareness.
Customer Specific – controls in which customers have full implementation and management responsibility. For instance, organizations are responsible for managing access and protecting external communications.
The second common approach to the shared responsibility model is based on the boundaries of responsibility. Namely, responsibility shifts depending on the level of the cloud deployment between the platform as a service (PaaS), infrastructure as a service (IaaS), and software as a service (SaaS). This approach is commonly used by Microsoft Azure, Google Cloud, and IBM Cloud:
In an IaaS framework, the provider is responsible for physical layers and shares responsibility with the customer for the security of the host infrastructure and network. All the rest is the customer’s responsibility.
In a PaaS framework, the provider also takes full responsibility for host infrastructure and network security, but it also shares responsibility with the customer at the application and access control levels.
In a SaaS framework, the provider takes full responsibility for application controls while sharing responsibility with the customer for access control as well as client/endpoint protection. Figure 2 visually demonstrates how boundaries of responsibility are shared:
FIGURE 2. (Source: Shared Responsibility for Cloud Computing. Microsoft Azure)
Understanding the key points of the shared responsibility model is essential while moving to the cloud. Cloud providers offer substantial advantages for ensuring security and compliance, but these advantages do not absolve organizations from protecting their applications and services. So, what happens if organizations do not keep their side of the bargain? What do cloud providers do to help customers uphold their end of the shared security responsibility? And what are the best practice guidelines that organizations offer to maintain data security? To answer these and other related questions keep reading our blog.