Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:00 AM
Dan Hubbard
Dan Hubbard
Connect Directly
E-Mail vvv

The Shared Irresponsibility Model in the Cloud Is Putting You at Risk

Step up, put the architecture and organization in place, and take responsibility. If you don't, who will?

A not-so-funny thing has happened as organizations have transitioned to the cloud: In many instances, they have also lost accountability and forgotten about critical responsibilities.

In the on-premises world, IT staff know they are responsible for the infrastructure on which applications are deployed. There are typically established procedures and policies for maintaining security compliance, risk, and breach detection. Perhaps more importantly, there is also typically a clear line of accountability about who is responsible for the operations, configuration, and security of a given system. And when there wasn't collaboration, the security teams wrapped in processes like change control and technology surrounding the infrastructure.

The cloud is a different model. Cloud providers are literally providing the infrastructure that organizations rely on — and in many cases, the services as well. Furthermore, the pace of innovation and frequency of change is such that old processes don't apply or slow you down. We live in an ephemeral world now.

Related Content:

The 'Shared Responsibility' Misnomer: Why the Cloud Continues to Confound

The Threat from the Internet—and What Your Organization Can Do About It

New on The Edge: h2c Smuggling: A New 'Devastating' Kind of HTTP Request Smuggling

Generally speaking, cloud providers are responsible for their own infrastructure, including hardware, networking, host OS, and hypervisor as well as providing a certain level of service and availability. But just because an application or service is running in the cloud doesn't mean that an end-user or organization is no longer responsible for security. All the major public cloud providers in recent years have embraced the concept commonly referred to as "shared responsibility."

The Shared Responsibility Model is pretty well understood now to mean: "If you configure, architect, or code it, you own the responsibility for doing that properly."

While the relationship between the customer and the cloud is well understood, our experience working with software teams indicates the organization and architectural security responsibilities within organizations are not. And that is where the Shared Irresponsibility Model comes into play.

Why Shared Irresponsibility Is Commonplace
When something goes wrong in the cloud — some form of security issue or incident —corporate management inevitably will come looking for the most senior person in the IT organization to blame.

The IT organization and development teams might not have gone line by line through the various cloud providers' Shared Responsibility Models to entirely understand what is and isn't something they have to deal with. Developers are focused on developing and getting code running, typically with high rates of change.

With the cloud, pushing code into production doesn't have many hurdles. The cloud provider is not responsible for an organization's own compliance, and, by default, it typically will not alert on misconfigurations that could introduce risk, either. So, neither the development team nor the cloud provider takes responsibility for security. Though this may sound harsh, both are functionally irresponsible.

The Shared Irresponsibility Model is a function of what happens in companies when everyone is focused on results and rapid deployment to make the most of the cloud. Its inevitable end state is finger-pointing within groups and organizations about who didn't do their job.

Bringing Accountability into the Cloud
In order to help fix this, there are four critical areas to invest in.

  1. Architectural and organizational
  2. Tooling and tuning
  3. Causation and correlation
  4. Workflow and automation

Architectural and Organizational
The gap between your development process and architectures cannot be light years ahead of your security architecture. If your security team is attempting to move a traditional security product into the cloud (aka cloud-washing), you will run into all kinds of hurdles. Security must have similar architecture cloud paradigms such as visibility in an ephemeral world, automation, policy as code, and real-time analysis. Your organization must also be aligned. DevOps needs to be aware of security guard rails and process and security needs to fit into the dev process, not around it. Cooperation and a clear understanding of triage, breach notification, and exposure to risk must be agreed upon between teams.

Tooling and Tuning
Like organizational silos, disparate tooling will also cause friction. Teams should be sharing the appropriate tool set and working from the same data or a "source of truth." Knowledge sharing on how tools are used, data is stored and queried, and a complete understanding of the output will allow teams to talk to a common language and help with tuning risk and exposures over time.

Causation and Correlation
One of the biggest benefits of cloud computing is the ability to run infrastructure as code and automatically provision up and down in near real time. Additionally, the rise of platform-as-a-service has allowed the deployment of storage, machine learning, API provisioning, and literally thousands of other services with a few lines of code. However, this incredible power also can expose organizations to risks and threats that otherwise were nonexistent and much easier to track in private data centers. A complete understanding of the change of this in your cloud environment is critical to success. The cause and effect and ability to correlate across services is also key.

Workflows and Automation
The most mature organizations understand and combine workflows across DevOps and security. This could be something as simple as a ticket-routing system, a more complex system like chat-ops integrations, or a complete automation workflow. However, if you do not have the appropriate architectures, shared tooling and data warehouses, and an understanding of change, this is very difficult.

The utopia of bridging the Shared Irresponsibility Model is just that. An automated system demands a complete organizational understanding in near real time of the risks and threats to your environment. Never assume that just because an application or service is in the cloud, that means someone else is securing it. Step up, put the compliance tools in place, and take responsibility ... because if you don't, then who will?

Dan Hubbard is CEO at Lacework, driving innovation and expanding the company's security strategy for public and private clouds. A pioneering force in Internet security, Dan's expertise spans from reputation and advanced classification systems to large-scale security data ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-14
An invalid free in Thrift's table-based serialization can cause the application to crash or potentially result in code execution or other undesirable effects. This issue affects Facebook Thrift prior to v2021.02.22.00.
PUBLISHED: 2021-04-13
A UXSS was discovered in the Thanos-Soft Cheetah Browser in Android 1.2.0 due to the inadequate filter of the intent scheme. This resulted in Cross-site scripting on the cheetah browser in any website.
PUBLISHED: 2021-04-13
The Motorola MH702x devices, prior to version, do not properly verify the server certificate during communication with the support server which could lead to the communication channel being accessible by an attacker.
PUBLISHED: 2021-04-13
A privilege escalation vulnerability in Lenovo Power Management Driver for Windows 10, prior to version, that could allow unauthorized access to the driver's device object.
PUBLISHED: 2021-04-13
A null pointer dereference vulnerability in Lenovo Power Management Driver for Windows 10, prior to version, that could cause systems to experience a blue screen error.