If you’re working in security, you know you’re on the hook to secure all the assets in your organization’s attack surface – including cloud and SaaS applications. But with employees signing up and adopting SaaS applications without your oversight, the scale of your attack surface has blown up without you even knowing it - leading to a huge increase in SaaS security risks. 

You’ve probably locked down the known cloud services and cloud apps your company is using (Google Workspace, Microsoft 365, etc.) and you have policies you’re already enforcing for how employees log into, access, and input sensitive data into cloud platforms like Salesforce and Hubspot. But what about all those other SaaS applications people in the company are using? Those apps make up a significant part of your attack surface. 

You need visibility into all those apps as the first step. We can help there and there are some semi-hacky ways you can even get this visibility on your own. 

I found all these shadow SaaS apps, now what?

Once you get the list of (likely hundreds) of SaaS applications employees have been using that you weren’t aware of, you’re probably then thinking about the next daunting task - how do I secure all these shadow SaaS or shadow IT assets across your SaaS attack surface to manage SaaS security risks?

That’s where the shared responsibility model comes into play. You’re not on the hook to take on every aspect of SaaS security, so let’s do a walkthrough of this model and we’ll help you hone in on where you can make the most impact when it comes to securing your sensitive data with every third-party SaaS vendor.

SaaS allows you to offload some operational security

You’re undoubtedly resource strapped, so using SaaS apps is a great way to delegate as many operational security tasks as possible to the cloud provider.

The shared-responsibility model shows you your responsibilities as the customer and which the cloud provider owns - this is one of the reasons SaaS is taking over the world.   

The following table produced by the National Cyber Security Centre (NCSC) shows how much of the balance of security responsibility is outsourced to the SaaS provider. For reference, IaaS = infrastructure-as-a-service; PaaS = platform-as-a-service; SaaS = software-as-a-service:

This table shows that in the SaaS model, you’re delegating a lot of responsibility for security to the vendor, which is great because it reduces the burden on your security team and SaaS providers are certainly best placed to secure their software. 

However, this requires far greater trust in SaaS providers. Even so, this is a net positive trade off for most organizations.

While we’re offloading a lot to SaaS providers, we aren’t offloading everything. You still need to take care of your responsibilities, even though they’re now quite limited.

How to handle your responsibilities for managing SaaS risks in your company 

So, how do you go about handling these two responsibilities highlighted in the table below?

1. Configuration of the SaaS app 

2. Manage identity and access controls provided by the app.

Configuration of the SaaS app

The way application configuration is presented in the NCSC table above is a bit of a red herring for the apps your employees will be self-adopting. The vast majority of SaaS apps (and especially self-adopted apps) allow very little, if any, security relevant configuration. 

Sure, the big core apps like Salesforce, Google Workspace, Microsoft 365 do (and often require a dedicated team or partner to run them), but they are highly unlikely to be self-adopted by employees. 

The issues that are likely to lead to a compromise are more likely to be related to the individual accounts on the app, rather than the app configuration - so in practice there may be little to do in terms of hardening most self-managed apps.

Manage identity and access controls, like MFA, provided by the app

You have a few options for handling this one. We’ll go through the key areas below:

1. SSO: Better yet, if there’s a way to tuck the app behind SSO, do it! SAML SSO is the ideal, gold standard solution for managing your SaaS security risks. The big issue is that very, very few apps, particularly the smaller ones most of the employees in your company will be signing up for, offer SSO integrations. 

When we looked at the apps we cover, only 30% of them offered SAML SSO integrations. 

Making things worse, of those few apps that did offer SAML SSO as a feature, they offered it as a paid feature that you can only access at a high pricing tier, typically Enterprise or the highest pricing tier. Many more apps offer social logins (aka OIDC SSO), and while this is not quite as good as SAML, for most organizations this is a far better option compared to local passwords for each SaaS app!

You’ve probably heard mutterings about this before and it’s even got its own site, called SSO tax, which gives you a sense of the huge number of apps without SSO integrations. See a screenshot of the site below:

At the moment, this means SAML SSO isn’t a practical option for most apps. We wrote much more on this here as well.

2. Encourage the other type of SSO — social logins: It's also smart to make your policy towards OIDC SSO a.k.a. Social Logins (“login with Google” or “login with Microsoft”) clear. Our advice is you should prefer social logins over usernames and passwords wherever possible. Read more about that here.

3. Employee trainings and education: Of course, you’ll want to (and typically, you’ll be required to) do regular security training for your employees.

If nothing else, make sure employees understand the value and impact of MFA and other identity access management tools.

Doesn’t delegating my responsibility increase SaaS security risks?

While delegating security responsibilities is great and takes a huge load off your security team, you need to consider who you’re delegating it to. 

This is what’s sometimes understood as supply chain security or third party risk management. You need to trust the SaaS provider to uphold their end of the bargain and, more often than not, also the SaaS/cloud vendors they use (their sub-processors) as well.

This sounds a lot scarier than it is. Many SaaS providers do a great job - they provide easy-to-audit, externally-verified, policies through a framework such as SOC2, and most do regular penetration tests and have bug bounty programs, etc.

And, before you panic about having to do a full security audit of every one of those hundreds of SaaS providers, know that there are tools that can help with this, which we’ll talk more about at the end of this article.

How to determine if you can live with the risk  

Here are a few things you might consider when you assess third-party risk: 

• The data going into these apps is simply too sensitive. 

  • Many organizations have very sensitive data, customer information or intellectual property (IP) that they simply aren’t willing to entrust to a third party. 

• The app requests administrative access to sensitive systems 

  • You may not want to trust a third party with administrative access to critical IT systems

If the sensitive data in the app or the access the app has represents some significant (but not unacceptable) risk, you may consider:

• The vendor has a string of repeated breaches or security incidents. 

  • This is troubling because it’s a fairly common pattern for attackers to breach apps in ways that don’t impact customer information, but then use the information they learn from these breaches to launch far more successful breaches in future and gain access to additional sensitive data. 

Consider the string of breaches at LastPass, Okta, Twilio (and many others) or as a typical example of this.

• The app doesn’t offer adequate security features. 

  • You want to see features like MFA, SSO (either social login through OIDC or, ideally, SAML), and bonus points for the ability to enforce these controls. This is especially important on platforms where the data is high-risk.

• They operate in a sanctioned country 

  • Clearly SaaS providers operating from (or that have close ties with) sanctioned or politically-complicated countries represent additional risk.

• The SaaS vendor may not have the resources to adequately protect your sensitive data. 

  • Also, question vendors that are so small that it is hard to imagine they can afford to spend significant resources on security. 

These are really common apps that integrate with your Google Workspace or Microsoft 365 - they add a feature or help streamline the employee’s workflow but aren’t a fully baked SaaS app with funding, a product and engineering team, or customer support.

If you can’t establish trust with a SaaS provider…

While the hope is that you can establish enough trust with third-party SaaS providers to allow employees to use the app, there will be exceptions.

Guide employees to secure alternatives early, before they invest too much time in a risky platform

Obviously, you can block the apps that you’ve deemed too risky for your company’s risk profile, which will reduce the attack surface. However, doing that in a vacuum, without working with the employees who are using (or testing) a SaaS application, can roadblock their work. 

While it solves your need for strong SaaS security, if you don’t provide employees with an alternative, more secure app to test, you’re burning all good will with the rest of the company. 

Worst case scenario, they’ll work around you to use the tool you removed by using their personal laptop or personal email to log in. 

The best path forward is to get into the SaaS adoption process early, as shown in this employee SaaS app adoption workflow:

The goal is to catch those apps that are high risk, either because the data going into them (or that will be) is high risk or because the app can perform some high-risk action (like managing your inventory or sending emails to customers or your behalf). 

By getting in early, you can focus your efforts on these high-risk vendors and apps to make sure they can be trusted with their data. 

We’ve written more about this here and it’s worth your time to read it, we promise. Blocking simply doesn’t work and it frustrates the team, so please consider this new way of securing SaaS. 

Try a tool to automate SaaS account security improvements

Check out SaaS security tools that don’t only look at the SaaS provider or the SaaS platform itself, but which also focus on the SaaS account or user identity level. 

Once you have visibility into which apps employees are using, you can dig into whether they’re using security features like MFA or using strong passwords. If they're not, use Push to equip them to enable MFA on their own:

Modern SaaS security solutions like Push can not only give you visibility into that information, but automate the process of reaching out to employees to help them turn on security features or updating weak passwords in a few short clicks.

Manage SaaS risk as scale without overburdening your team

When facing a list of hundreds of apps that employees are using in your business, doing due diligence feels like a daunting task. Push can help with this as well.

You can classify SaaS apps directly in the Push platform based on:

• the sensitivity of the data they contain

• the permissions they've been granted using the Sensitivity level field

Then use the Approval status option to capture your decision about an app.

This helps your team suss out the risk so you can make the right choice, without having to have discussions in side channels. Read more about how this works.