It’s time for a new SaaS shared responsibility model

Imagine walking into a busy airport in a stylish suit—well-fit, not too baggy, not too restrictive. You navigate the crowds, cruise through TSA pre-check, and breeze up to your gate. There’s an open seat right next to the gate—today is your day! As you settle in, you realize your computer is running low on battery, so you dig through your bag for the power cord. As you sit up, you realize a sneaky thief has snatched your passport from the seat next to you. 

‍

Who’s to blame?

‍

This is a classic example of a “shared responsibility model.” The TSA is responsible for screening passengers and luggage to keep the plane safe and head off major terrorism events. They make sure that weapons, dangerous chemicals, and your economy-size toothpaste tube don’t make it on the plane. But securing your personal belongings within the airport? That’s your responsibility. 

‍

In the world of cybersecurity and compliance, this model was brought into focus with the transition to the public cloud—we had to reassess which aspects of security we retained responsibility for, and which became the domain of our cloud provider. The same concepts apply to the use of IaaS (public cloud), PaaS, and SaaS—each with its own line demarking where the “customer’s” responsibility begins and ends in terms of secure use of the service. 

‍

At first blush, the SaaS shared responsibility model is intuitive and manageable. I use Salesforce: they secure the operating environment, and the software; I am responsible for ensuring the right users have the right access to the right data and that I am properly using the software’s security features. (I’m simplifying here, as Salesforce has about a billion and a half permutations of security features you can use, but the core concept remains.) However, this shared responsibility model has a critical flaw: it assumes the actual user on the other side of the service is capable of managing their part of the responsibility. 

‍

With a core enterprise service such as Salesforce, we can assume that an IT or security professional would likely handle the configuration during rollout. But for more than 90% of the services your organization uses, this is not the reality. Based on analysis of our customers’ data, we can determine that more than 90% of the time, the employee who first introduces a SaaS app to the organization works outside of the IT organization. This means more than 90% of the time, the SaaS shared responsibility model is shared not with the IT organization, but with that user who first signed up. That user will end up making critical decisions about who gets access to the app, how it’s configured, and which security features to enable. 

‍

Indeed, the PLG model that dominates modern SaaS adoption disrupts the SaaS shared responsibility model. That model is based on a core assumption that there is a security-conscious user to share responsibility with. With product-led growth, the goal of the SaaS provider is to get one of your employees to use the product and expand the adoption from there. Often this is coupled with free tiers and trials, which make it easy for employees to get started without a credit card or dealing with procurement. 

‍

It is perfectly reasonable for a SaaS provider to draw a line and denote what the customer needs to take responsibility for when it comes to security—but when that same SaaS provider allows any employee to become the first (and often only) admin, we have an issue. This is further aggravated by the fact that many SaaS providers won’t even tell a company who has signed up for their service (ahem, AWS, Dropbox, Box.com). So now we have a situation where we need to have confidence that any employee in our organization who introduces a new SaaS app has the security expertise and the motivation to handle their share of the security of the services they use before they upload any sensitive data or integrate it with other business-critical services. 

‍

What’s more, in the recent threat campaign targeting Snowflake customers, Snowflake itself was likely an officially sanctioned app at most companies. This means the traditional control of “block the stuff we don’t want to allow” falls on its face—the difference between traffic going to the approved instance of an app and a shadow instance created by the employee is non-existent.

‍

It's time to reassess the customer side of modern SaaS security shared responsibility model. It's no longer safe to assume that the responsibility lies solely with the organization's IT security team. Instead, business technologists or non-IT SaaS owners share the responsibility. Even individual end users have personal responsibilities related to SaaS use, such as enabling MFA on each SaaS account, deleting accounts they no longer use, and following the organization’s acceptable use policies. That said, we can’t rely on good intentions or vague memories from the annual security training—employees need reliable, just-in-time guidance to make decisions and take actions that strengthen their organization’s security posture.

‍

To achieve this kind of guidance, organizations need a strong mechanism for identifying not only what SaaS is being used by their employees, but also the instances of those SaaS apps, and who the privileged stakeholders are who manage them. Traditional detection techniques (network- or finance-based approaches) simply can’t provide this kind of granular data. 

‍

Given the rise we are seeing in campaigns targeting SaaS instances, we need a new SaaS shared responsibility model—one based on a foundation of complete and continuous SaaS discovery, and the ability to guide employees toward safe, compliant SaaS use in real time. There is no longer room to simply assume that our frontline employees are doing everything they should do, nor to assume that our traditional controls are keeping SaaS sprawl in check. 

‍

A shared responsibility model for modern SaaS security

So, how do we at Nudge Security envision the future of shared security responsibilities? Here's an overview.

‍

IT security & compliance governors

Generally accountable for defining and verifying compliance with corporate standards for technology use

‍

SaaS owner / admin

Generally accountable and responsible for the judicious application of corporate-wide policies in the context of the specific app environments they own / administer.

‍

SaaS end user

Generally accountable and responsible for ensuring that individual use of SaaS and AI apps are in compliance with corporate standards

‍