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
When It Comes To Security Tools, More Isn't More
Lamont Orange, Chief Information Security Officer at Netskope,  1/11/2021
US Capitol Attack a Wake-up Call for the Integration of Physical & IT Security
Seth Rosenblatt, Contributing Writer,  1/11/2021
IoT Vendor Ubiquiti Suffers Data Breach
Dark Reading Staff 1/11/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-18
An issue was discovered on ASUS DSL-N14U-B1 devices. An attacker can upload arbitrary file content as a firmware update when the filename Settings_DSL-N14U-B1.trx is used. Once this file is loaded, shutdown measures on a wide range of services are triggered as if it were a real update, r...
PUBLISHED: 2021-01-18
Affected versions of Atlassian Fisheye & Crucible allow remote attackers to browse local files via an Insecure Direct Object References (IDOR) vulnerability in the WEB-INF directory. The affected versions are before version 4.8.5.
PUBLISHED: 2021-01-17
An issue was discovered in Quali CloudShell 9.3. An XSS vulnerability in the login page allows an attacker to craft a URL, with a constructor.constructor substring in the username field, that executes a payload when the user visits the /Account/Login page.
PUBLISHED: 2021-01-17
Netsia SEBA+ through 0.16.1 build 70-e669dcd7 allows remote attackers to discover session cookies via a direct /session/list/allActiveSession request. For example, the attacker can discover the admin's cookie if the admin account happens to be logged in when the allActiveSession request occurs, and ...
PUBLISHED: 2021-01-15
An issue was discovered in Malwarebytes before 4.0 on macOS. A malicious application was able to perform a privileged action within the Malwarebytes launch daemon. The privileged service improperly validated XPC connections by relying on the PID instead of the audit token. An attacker can construct ...