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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/27/2020
Chinese Attackers' Favorite Flaws Prove Global Threats, Research Shows
Kelly Sheridan, Staff Editor, Dark Reading,  10/27/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-28
NeoPost Mail Accounting Software Pro 5.0.6 allows php/Commun/FUS_SCM_BlockStart.php?code= XSS.
PUBLISHED: 2020-10-28
osCommerce Phoenix CE before allows admin/define_language.php CSRF.
PUBLISHED: 2020-10-28
osCommerce Phoenix CE before allows OS command injection remotely. Within admin/mail.php, a from POST parameter can be passed to the application. This affects the PHP mail function, and the sendmail -f option.
PUBLISHED: 2020-10-28
Shibboleth Identify Provider 3.x before 3.4.6 has a denial of service flaw. A remote unauthenticated attacker can cause a login flow to trigger Java heap exhaustion due to the creation of objects in the Java Servlet container session.
PUBLISHED: 2020-10-28
The Snap7 server component in version 1.4.1, when an attacker sends a crafted packet with COTP protocol the last-data-unit flag set to No and S7 writes a var function, the Snap7 server will be crashed.