Why the classic physics challenge might feel familiar to those operating within the “shared security model” for SaaS applications.
The “three-body problem” is a classic physics concept that illustrates the challenge of determining the trajectories of three objects orbiting one another in space. (It was also popularized by a book of the same name by Cixin Liu, and more recently a TV adaptation on Netflix). The challenge in the classic physics problem is the constantly shifting gravitational forces exerted by one body on the other two, which dramatically complicates the process of predicting the subsequent trajectory of any of the bodies. This dynamic might feel familiar to those operating within the “shared responsibility model” for SaaS applications.
The shared responsibility model, or its modern derivation, the “shared fate model,” was first brought into the mainstream dialogue of cybersecurity by cloud computing providers like AWS. They used the phrase to describe and delineate the realms of responsibility for the cloud provider and the customer in terms of implementing, monitoring, and enforcing security controls. In such environments, the cloud provider handles a large portion of the responsibility—but not all. The customer is always responsible for the last mile. The industry has since come to terms with the practical reality of such a model, and vendors such as Wiz have provided additional security controls to help the consumers of these cloud providers to better manage their portion of responsibility.
When it comes to software as a service (SaaS), the provider takes on a much larger portion of the shared responsibility. Where a cloud provider may draw the line at the operating system, the SaaS provider takes on the operational responsibility for the entire software stack up to the application logic. That last little bit means the customer still retains responsibility for the provisioning of accounts, the appropriate use of security features, the oversight of integrations, the safe use of collaboration features, and much more depending on the nature of the app.
The unique challenge of SaaS is that there are three distinct users within an organization that share responsibility with the SaaS provider: the end user, the administrator, and the security team. This is further complicated by the broad spectrum of approaches that SaaS providers offer in the implementation of security features.
Many SaaS providers embrace a product-led growth (PLG) model for customer acquisition. We’ve all experienced the benefits of this model, as we’ve started a free trial or used a free tier of an app to validate its functionality and applicability to our purposes. However, what’s almost always overlooked is the responsibility one assumes the moment they create that account. Every app, after all, requires that the end user assumes some portion of the shared security model. From entering a secure password to making prudent selections around file-sharing, or which security features to enable, consequential decisions are made by the end user of an app.
From here, a complicated dynamic arises between the responsibilities of the three user profiles outlined above. In some apps, the end user takes on substantial responsibility and in others, those decisions are made by the administrator. Both users likely require oversight and guidance from the security team. As an example, up until a few weeks ago, multi-factor authentication was a feature that end users of the popular Snowflake app had to opt into. With recent updates, it is now a feather that administrators can enforce. Great, right?
Unfortunately, we’re not quite out of the woods yet: Snowflake uses a PLG model for customer acquisition, so the administrator of the app may not be a security-informed user, but the first user of the trial. These dynamics are prevalent across the SaaS ecosystem. The first user of an app is anointed the administrator and owner of the instance by default. This creates a sprawl of users who may or may not have the awareness or expertise required to ensure the secure use of that app and its security features.
In the end, the security team ends up being accountable for all of these SaaS apps and the corporate IP, the customer lists, and the financials that they store. A security failure falls squarely in their lap. So now we have the security team that is required to have domain expertise across all of these apps, but rarely has access to them, and is often completely unaware of their existence.
The constantly shifting dynamic of the SaaS shared responsibility model starts to make three orbiting bodies seem, well…easy. We need a new 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.
Here’s how I envision the future of shared security responsibilities between the IT security and compliance governors, the SaaS admin, and the SaaS end user:
.png)
