SaaS and the Shared Security Model

Originally published by Suridata.

Written by Haviv Ohayon, Co-Founder & COO, Suridata.

Who is responsible for securing digital assets in the public cloud, the customer, or the cloud service provider (CSP)? Most of the time, it’s both. CSPs require their customers to agree to what’s known as a Shared Security Model, sometimes called the Shared Responsibility Model. In this approach to cloud cybersecurity, the CSP is responsible for securing their own infrastructure, but the customer is on the hook for almost everything under its control, such as application security and identity management. The Shared Security Model makes a great deal of sense, especially when the division of control is clear, such as in the case of Infrastructure-as-a-Service (IaaS). With Software-as-a-Service (SaaS), things get a little more complicated. This article looks at how SaaS security works under the Shared Security Model.

What is the Shared Security Model?

The Shared Security Model is embedded in the “fine print” of the contract the customer signs with a CSP. In fact, the word “model” is not quite right. It should really be called the shared security responsibility agreement. When you sign up with a CSP, you’re assigning yourself several critical security duties, with disputes potentially ending up in court. So, pay close attention here…

Briefly, the Shared Security Model holds that the CSP is obligated to protect its data centers, internal networks, and the hardware that supports its cloud platform. This means securing internal software development workflows and complying with security standards. It also involves monitoring infrastructure for threats, mitigating those threats, and responding to security incidents.
The SaaS provider is responsible for protecting its way of using of the applications and data it hosts on the CSP’s infrastructure.

It’s a good practice to develop a sophisticated, detailed understanding of just what is, and isn’t covered by the CSP’s side of the model. Think of the cloud platform stack. With IaaS, the CSP secures all infrastructure components on its side, including servers, network switches, and so forth. The customer may be on the hook for the operating system (OS), database server, application software and identity and access management (IAM). With Platform-as-a-Service (PaaS), the CSP usually secures the platform software, such as Linux, because that’s part of the service they’re providing. Always check, however. It is not wise to make assumptions about the CSP’s specific areas of responsibility.

The Shared Security Model comprises a logical set of rules sense for both the CSP and the customer. The CSP has little to no control over the way its customers deploy and configure their systems. Nor can the CSP control the customer’s endpoints. If the customer does not regularly patch its OS, for example, that is a deficiency the customer has to address.

SaaS and the Shared Security Model

The Shared Security Model for SaaS is different from those utilized for IaaS and PaaS, for several reasons. With SaaS, the vendor is the application provider and the cloud provider. In some cases, the SaaS vendor runs the SaaS application on a CSP like Microsoft Azure. In that scenario, the CSP is obligated to the SaaS vendor under the Shared Security Model, but the SaaS customer still has its share of security responsibilities.

The SaaS vendor is responsible for application security. This includes protecting the data stored by the SaaS app. However, the customer is responsible for data security, as well. This may sound confusing but remember that a threat to SaaS data can come from an attack on the cloud infrastructure or through the SaaS interface or application programming interface (API). In the latter attack surface, the customer is responsible.

With SaaS, the customer is also responsible for its endpoint security and user security. It is up to the customer to protect itself by preventing unauthorized access to the SaaS application. In practice, this means the customer takes care of IAM, user security and credentials, configuration, APIs and middleware.

How to Manage SaaS Security in the Context of the Shared Security Model

Managing SaaS security under the Shared Security Model requires attention to detail. It’s essential to do a careful review of the terms of the agreement and any Service Level Agreements (SLAs) it contains. The customer is protected by the legal agreement, but it’s wise to keep in mind a basic fact of life in IT: If you end up in a lawsuit, even a lawsuit you win, you are not succeeding. The best approach is to understand your responsibilities and translate the most urgent of them into clear assignments for all relevant teams and stakeholders.

Data security should be a priority, for instance. Know what data you have in your SaaS application, how it’s protected, and who has access to it. This means implementing IAM that defines and enforces cloud access policies. Privileged Access Management (PAM) needs to be part of this thought process, too.

It’s also smart to know where your SaaS application is integrating with other SaaS applications, as well as with other parts of your IT estate. The SaaS attack surface can be quite a lot larger than you realize, once you start factoring in all the ways a malicious actor can access a SaaS application beyond its front-end user interface.

A security partner can help, too, as can solutions for SaaS security posture management. Keeping track of number of SaaS configurations can be overwhelming, especially with the added burden of figuring out what is your responsibility and what is covered by the SaaS vendor. Technologies that automate SaaS security posture management can be quite helpful in minimizing risk to SaaS applications.