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

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.

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.

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?