Agile Digital Transformation

Agile Digital Transformation

Subscribe to Agile Digital Transformation: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Agile Digital Transformation: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Agile Digital Transformation Authors: Pat Romanski, Elizabeth White, Liz McMillan, Nate Vickery, Kevin Benedict

Related Topics: Agile Digital Transformation

Blog Feed Post

Cloud Security Pitfall: Understanding the Shared Responsibility Model

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.

Read the original blog entry...

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).