The early days of the public cloud saw enterprises reluctant to put anything but low-risk, non-mission-critical applications in the cloud.
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.
The most significant of these concerns has always been, of course, security. As IT executives came to realise that public clouds could offer more secure infrastructure than they could implement in their own data centres, many of the hesitations to the cloud fell away, leading to ‘cloud-first’ strategies for many top enterprises.
However, whilst leading public cloud providers boast their almost bulletproof security, we still see some rather embarrassing breaches in said clouds. Why?
The problem is not with the security of the cloud infrastructure itself, but rather how cloud customers manage their own security inside the cloud.
The Blame Game
As we have all heard many times before, all public cloud environments work on a shared responsibility model, where cloud providers are only responsible for securing their own cloud infrastructure. Cloud customers, however, are responsible for managing and configuring their cloud environments properly in the context of their overall cloud strategy.
Not only does the Shared Responsibility model refer to security, it extends to the sharing of management, operation, and verification of all IT controls.
Cloud providers do offer a variety of tools within their environments that customers can use to establish to their unique business and cloud goals depending on their requirements and network needs. However, it is always up to the cloud 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.
A Multi-Tiered Approach
A cloud customer’s technical staff, in particular the architects who are responsible for the overall cloud deployment and operational plan, including the configuration for IT controls, could be said to suffer the burden of evading such finger-pointing.
The organisation’s IT team is still accountable for data and application security, as well as regulatory compliance. Thus, enterprise cloud and security architects must warrant that everyone within the organisations – including security, networking, application, and cloud teams – are accurately deploying applications and workloads within the context of the organisations security and compliance policies.
Below is a diagram that illustrates the customer and cloud provider sides of AWS’s shared responsibility model.
The AWS Shared Responsibility Model (Source: AWS)
Policies are central to the implementation of sufficient security – not merely the policies explicit to the configuration of individual cloud services, but policies regarding the IT organisation’s use and configuration of the cloud within the context of overall IT strategy.
Security, however, doesn’t simply operate at this 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.
Organisations 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.