In the early days of the public cloud, enterprises were reluctant to place anything but lowest-risk, non-mission-critical applications in the cloud. Public-facing web sites and the like represented much of this early cloud traction.
As the cloud matured, enterprise decision makers became more comfortable with moving mission-critical apps to the cloud. For such applications, the scalability, cost, and ease-of-use benefits outweighed their concerns for an increasingly wide swath of their application portfolio.
Security, of course, has always been the most significant of these concerns. As IT execs came to realize that public clouds could actually offer more secure infrastructure than they could implement in their own data centers, many of the reservations to the cloud fell away, leading to ‘cloud-first’ strategies for many top enterprises.
Yet, while all the leading public cloud providers tout their nearly bulletproof security, there have also been a raft of embarrassing breaches in those same clouds. What’s going on here?
The problem is not with the security of the cloud infrastructure itself, but rather how cloud customers configure their own security inside the cloud.
The Finger-Pointing Problem
All public cloud environments work on a shared responsibility model in which cloud providers are responsible for securing their own cloud infrastructure. Cloud customers, however, are responsible for configuring their cloud environments properly in the context of their overall cloud strategy.
The shared responsibility model also extends to IT controls beyond those specific to security. Just as the customer and cloud provider share the responsibility to operate the IT environment, the same parties must share the management, operation, and verification of all IT controls.
To ease these requirements, cloud providers offer a variety of tools within their environments that customers can use to establish the appropriate controls for their particular situation. However, it is always up to the customer to understand how to properly configure and implement such controls.
When a breach occurs, however, customers are likely to point fingers at the cloud provider as being at least partially culpable for such a breach. After all, it promised that its cloud was secure, right?
From the cloud provider’s perspective, the responsibility for proper configuration of security controls is squarely in the customer’s domain – and the legal contracts between customer and provider are sure to delineate this fact.
This finger-pointing exercise never improves matters, and instead reinforces an adversarial relationship between provider and customer where a collaborative relationship would be both more productive and more secure in the long run.
Taking an Abstracted, Multi-Tier Approach
The burden of avoiding such finger-pointing falls upon the customer’s technical staff – in particular, the architects who are responsible for the overall cloud deployment and operational plan, including the configuration of IT controls.
Enterprise IT is still responsible for data and application security, as well as regulatory compliance. As a result, enterprise cloud and security architects must ensure that everyone within the organization –including security, networking, application, and cloud teams – are properly deploying applications and workloads within the context of the organization’s security and compliance policies.
The reference architecture these professionals hammer out, therefore, must include both the customer and provider sides of the shared responsibility model in a single, unified abstraction layer. Such an architecture must be both policy-based as well as multi-tiered.
The diagram below illustrates the customer and cloud provider sides of AWS’s shared responsibility model – a template that Microsoft Azure and other cloud providers have generally followed.
The AWS Shared Responsibility Model (Source: AWS)
Policies are central to the implementation of adequate security – not simply the policies specific to the configuration of individual cloud services, but policies regarding the IT organization’s use and configuration of the cloud within the context of the overall IT strategy.
Security, however, doesn’t simply operate at this abstracted, policy-centric level. To mitigate security risks in today’s rapidly evolving threat landscape, security personnel must complement traditional security approaches with additional detection and response techniques in order to uncover anomalies and other issues across the entire hybrid on-premises/cloud environment.
In other words, trust but verify. Enterprises must trust their cloud providers to implement their part of the security equation, while leveraging the appropriate tooling to obtain sufficient visibility into the cloud environment to ensure end-to-end security.
The Intellyx Take
Understanding and adopting a true shared responsibility model is a critical activity that one blog post cannot do justice. This is, therefore, the first part of a four-part blog series on this important topic.
In part two of the series, we’ll discuss the respective concerns of the security architect and the network architect. We’ll explore how people in these roles must change their thinking about how they work together to achieve the business goals for the applications they support, including security.
Then, in part three, we’ll dive into the security challenges inherent in hybrid IT and multicloud deployment architectures, within the context of the shared responsibility model and the organizational changes we discuss in the first two posts.
By the time we get to part four, we’ll be able to fill in some of the technical details of the multi-tiered security model that provides visibility into virtual machine network traffic – a particular challenge in public cloud environments that hide the details of their internal network configurations from their customers.
The shared responsibility model can lead to vulnerabilities. The challenge enterprises face is not simply ensuring that they’ve configured cloud services properly, but in implementing a comprehensive, well-architected strategy for security and compliance across all environments, both on-premises and in the cloud.
Copyright © Intellyx LLC. Gigamon and Microsoft are Intellyx clients. At the time of writing, none of the other organizations mentioned in this article are Intellyx clients. Intellyx retains full editorial control over the content of this paper.
