Cloud Providers Must Own up to Their Part in the Current State of Insecurity

This edition of SaaS Risk Insider features a special guest post by Andy Ellis, a 2021 Inductee into the CSO Hall of Fame and partner at YL Ventures. We're honored to share Andy’s insights with our readers with this article that was originally published on CSOOnline.com.

The shared responsibility model has been foundational to cybersecurity from the start. But modern developments and complications, especially in the cloud, are beginning to erode our ability to truly share responsibility for secure results.

The premise of shared responsibility is that a vendor is responsible for building a system that can be secure, and the organization that uses the system is responsible for implementing the system securely.

Consider the safe. One of the oldest security technologies around, safes are relatively easy to understand from a shared responsibility perspective: The manufacturer builds a box with a lock on the door, and you install it in your office (or home, or secret underground lair, or …).

The manufacturer has obvious responsibilities. It needs to ensure the walls of the safe aren’t easy to breach, the hinges on the door aren’t easy to disconnect, and the lock isn’t easy to pick. The manufacturer even provides specifications for how long the safe will endure various forms of attack.

The buyer also has responsibilities when installing the safe. This includes how it is bolted in, who has access to it, and how it is protected from extreme force. The combination or key to the safe should also be kept secure from an adversary — a sticky note nearby with the combination is a bad idea.

Shared responsibility in IT isn’t so simple

As technology becomes more complex, the model becomes more strained. When physical technologies become obsolete or vulnerabilities come to light, we often face a binary choice: to keep using the flawed system or to replace it outright. But with computing technologies, we have a new option: upgrade in place.

In early computer systems, these upgrades took the form of patches: new pieces of software that modified the behavior of existing systems. The software vendor had the responsibility to make sure the new software mostly worked — and when it didn’t, like the vulnerability that led to the Slammer worm, we have really bad days. The buyer “just” needed to install the software.

Even when software worked in a lab, it didn’t always work in real environments. Application ecosystems are complicated, and vendors had to navigate the myriad ways their software might be used, including which operating systems it would be installed on and what applications would rely on it.

The easiest solution became configuration-driven updates: Rather than releasing a patch that disabled old functionality while implementing new capabilities, the new software contained both options, and a new, user-configurable setting would be available. The vendors “shared” the responsibility for the user to manually enable this new setting — and if it broke things, the user could just disable the setting rather than having to manually reinstall old software.

Backwards compatibility takes us … backwards

Unfortunately, once you keep support for old, vulnerable versions of your software, people will continue to use old, vulnerable versions of your software.

Vendors shrugged their shoulders, and pundits blamed software users for choosing to use a working-but-vulnerable version instead of a broken-but-patched version (as if that was a real choice). And as more users continued to use the vulnerable features, vendors had to continue to support the vulnerable versions, which enabled more users to rely on the vulnerable features, which … you get the picture.

Software has mostly stopped being single-purpose, where a vendor can understand exactly how their customers will use it. Instead, it’s become general purpose, with most software doing very simple things well but being used in highly unpredictable ways. And no longer does an IT team even install most software because most organizations are no longer “metal-native” — owning their own computer systems — but are instead cloud-native, SaaS-native, and AI-native.

Building castles in the cloud

As companies started relying increasingly on software they didn’t control, they lost even the signal that a software vendor had updated its software choices. Initially, as more applications used CDNs to host their websites, these CDNs often had insecure settings. It wasn’t until 2013 that CDNs could securely validate SSL/TLS certificates at the origin. Due to the high costs involved, CDNs “let” customers manage their own secure configurations.

While CDNs had to deal with the complexity of any number of origin and end-user systems they talked to, that was relatively simple compared to the challenge of the cloud service provider (CSP) world, where the likes of AWS, Azure, and GCP operate. Not only do they have to support innumerable single-cloud configurations, but their customers also want to use their software in hybrid and multi-cloud environments.

The memorable CapitalOne breach is a classic example of the challenge of correctly configuring things in the hybrid cloud world. A proxy service in AWS handled authentication, and while it had a (relatively) simple configuration when every request came from within the AWS environment, it needed a more complex configuration to handle requests that came from outside (where the hybrid environment was located).

In the wake of the breach, AWS released several new capabilities and guides but disavowed any responsibility for CapitalOne’s imperfect implementations.

Lack of responsibility leads to a lack of incentives

Entire industries — from ecosystem hardeners like cloud-native application protection platforms (CNAPP), SaaS security posture management (SSPM), and cyber asset attack surface management (CAASM) to application defenders such as application security posture management (ASPM), application detection and response (ADR), and web application and API protection (WAAP) — have risen (and some fallen) just to try to help companies protect their applications inside these dangerous ecosystems.

Every day, it gets harder. CSPs release new capabilities at an astounding rate, and each needs safe configuration. Old capabilities are silently updated with new security features to fix known issues, but customers are expected to stumble onto new documentation and notice the changes entirely on their own.

Cloud providers need to stop denying that they hold some fault in the current state of insecurity. Their security tooling needs to be easier to use at scale. Unsafe configurations must be easy to identify, and when they do discover problems, they should bear the burden of helping their customers become more safe.

The complexity of securing SaaS environments isn’t slowing down—it’s accelerating. Shadow SaaS, misconfigurations, and evolving cloud capabilities make it harder than ever to maintain security and compliance. Grip’s?SaaS Security Control Plane,?Grip Extend User Security, and?Grip SSPM?provide the visibility, governance, and automation needed to stay ahead of SaaS and identity risks. Schedule a demo today and see how Grip makes securing SaaS simpler, smarter, and scalable.