The no-jargon guide to solving shadow SaaS

Introduction

Here’s hoping you’ve read my previous blog: SaaS sprawl isn't a problem - if you completely change your approachIf you haven’t, the key takeaway of that piece is that SaaS vendors have changed how software is adopted into a business. Now, the majority of SaaS vendors build their products on a product-led growth model - which simply means they want users (your employees) to self-adopt their apps, start using them (and integrating with your data to do so), and become a useful tool for the employee. 

Vendors want to bypass the security and IT software-onboarding processes we’d all gotten used to in the past. They know if they prove their tool is valuable with the user from the start, it’s much easier and quicker for them to gain traction and customers than it was waiting for security and IT teams to audit (and potentially refuse) their software.

This self-adoption has turned the product-adoption process on its head - leaving security and IT teams blind to which apps sensitive company data is flowing into. 

How do you make sure your data stays secure in this new software-adoption flow? 

In this book, we’ll offer some practical guidance on how to manage supply chain risk without slowing down the business.

We’ll cover how to:

• Split SaaS risk into supply chain risk and account compromise risk so you can tackle them in parallel.

• Tap into the SaaS self adoption process in real time so you can manage supply chain risk without being a blocker. 

• How to prioritize account security controls and prevent the most common SaaS attacks.

• Better choose a SaaS security product by looking at the data these tools are built on.

The two halves of SaaS Security

As a quick recap from my last ebook, it’s useful to consider the shared-responsibility model to understand the two main parts of SaaS security. Consider the following diagram that shows the customer’s responsibility in various as-a-Service models:

In this SaaS model, we’re delegating a lot of responsibility for security to the vendor. That’s great because it takes the load off of us - the customer - and the vendor is better placed to secure their software. However, this requires far greater trust in the vendor.

While we’re offloading a lot to the SaaS vendor, we aren’t offloading everything. You still need to take care of your responsibilities, limited as they are!

This gets us to the two halves of SaaS security:

• Supply chain risk - can you trust the product, the vendor, and the vendor’s sub processors to secure your data and the access you grant them to your systems?

• Customer responsibility - how can you make sure you’re using the product securely? You’ll need to focus here specifically on account security and application configuration.

Let’s look at each of these in turn.

Manage supply-chain risk

Security due diligence or app risk assessments are typically how you answer the question “should we use this app?” These are standard processes for most organizations as part of a software procurement process.

However, as we discussed in our introduction and in my last book, security no longer controls the cadence of software adoption - employees are self-adopting the tools they want without oversight - so we must work to find serious risks as soon as possible once the self-adoption process begins (normally by the first employee creating an account on the app).

The security relevant areas of this risk assessment can typically be broken into:

• Product risk 

  • Does the product have the necessary security features (MFA, SSO, etc.) to protect our data, and 

  • Has the product security been technically verified (e.g. through a third party penetration test)?

• Vendor risk 

  • Does the vendor have the resources to secure the product? 

  • Have they invested in a security team and implemented appropriate security processes?

  • Have those processes been independently audited (e.g. SOC2)? 

  • Does the vendor operate in a high risk region?

  • Does the vendor have a history of repeated security incidents?

• Vendor sub processors - the majority of SaaS applications are build on other *-as-a-Service platforms. These vendors are also part of your supply chain. Just because you don’t directly use a tool or app doesn’t mean you’re not affected when they’re popped. Realistically, you’re probably not going to be able to go very deep here, but when you’re wondering whether you’re affected by a breach in the news, you may want to know whether your vendors are using the affected SaaS app. 

Ultimately, how much you care about any of the above comes down to the risk of the data in the application or the level of access you grant this application into the rest of your infrastructure (often through integrations with other SaaS apps). 

Therefore, a useful first step to knowing where to prioritize your time is to understand the sensitivity of the data and access granted to the app (or that will likely be granted by employees in future to make the app work as expected).

For self-adopted SaaS apps, aspects that are typically very important for software procurement like legal agreements (terms and conditions, master service agreements etc.), spend (through licensing cost etc.), and uptime and availability (SLAs etc.) are typically dealt with after the app has been adopted. Often, this comes up once employees need to upgrade to a paid account or higher license tier, or once it makes financial sense to commit to longer term agreements. 

For that reason, I recommend you keep the security risk assessment focused on the direct security aspects initially so you reduce the work required to ask “is there a security reason to stop our employees from using this app right now?”

All of the above is relatively straightforward advice, but there are some very practical non-obvious lessons learned from others who've walked this path already that are worth highlighting, so let’s jump into those.

Focus on the new stuff first

It’s both technically, and politically, very difficult to migrate users away from apps, especially when users have invested significant time into setting up an app and love how it works. It’s hard to spend the goodwill you’ve built up on something like this unless there really is a truly unacceptable risk or compliance issue.

There is an exception to this - if you get in before employees have sunk too much time and effort into an app they are far more open to input and steering. This is why we recommend that you focus your risk assessment efforts on new apps and integrations, rather than spending the majority of your time working through the backlog of already-adopted work apps.

If you focus on apps that are still in the testing phases, it's much easier to steer the course towards lower-risk alternatives or pump the brakes when there really is significant risk to the business.

Buy yourself time

Remember, even the newest apps will only be new for a brief time. Once employees have invested significant time into an app (learning how it works, putting data into it, etc) they will be resistant to considering alternatives and will push to accept risks rather and make exceptions to policies rather than moving to an alternative app. This is just natural, but it does mean that there is a clock running for you and your team as soon as an employee creates an account on a new SaaS app.

Your goal is to give your security team as much time to assess the app before the employee decides for sure they want to use it for work. 

It’s far less useful if you discover an app once the team is talking to finance about upgrading to a paid subscription. At that point, so much time and effort has been invested that it’s very difficult to motivate employees/teams to move to a lower-risk app. In this scenario, you’ll be stuck in a “let’s do as much as we can to secure this” mode, which isn’t ideal.

The way to give the security team as much time as possible is to reduce the delta between an employee signing up for an account and the IT and security teams finding out about it. You need a way to find out about new apps being adopted in real-time or within hours, rather than days or weeks. The tools to do this exist, but more on how you should choose the right tool in the “importance of choosing the right data source” section.

You need accurate data to take action

To discover SaaS apps and simply inventory which apps are being used for reporting purposes, you won’t need perfect accuracy and you’ll be able to live with some false positives.

Most security teams start out just by getting visibility of what SaaS is being used across their business. Then you know what you’re dealing with. The downside is that you’ll want to use this data to spin off a risk assessment process. If you are kicking off risk assessments based on false positives, that’s just pure wasted effort.

You will likely also want to get in touch with the employee that adopted the app, for example to understand their intended use-case and the data that might be going into the app. Employees will also notice quickly if the security team can’t tell the difference between accessing an app website or using an app and get annoyed with the interruptions from your team.

Many tools will use things like scanning employee email inboxes or network-level data to “discover employee SaaS use,” but this leads to a frustrating rate of false positives for your team. If the security team needs to first confirm if a data point is a false-positive through some unspecified process, then that seriously increases the work needed to take action. 

At the risk of sounding like a broken record, accurate data is the thing that turns this problem from something that’s impossible to something which is manageable, even at scale.

Customer responsibility for self-adopted SaaS

As a reminder, I’m referring in this section to your responsibility as a customer (highlighted in purple) in terms of NCSC’s shared-responsibility model shown below:

Let’s start with the bulk of the work, which for self-adopted SaaS is account security. This includes all the usual suspects like ensuring that, you’re:

• Enabling MFA for all accounts

• Encouraging employees to use strong passwords (ideally through a password manager)

• Using SSO,where possible and practical

• Reviewing access delegated to third-parties (through e.g. OAuth integrations) 

In contrast to SaaS apps like Office 365 or Salesforce that are extraordinarily configurable and often have teams managing and securing them, there’s some mixed news when it comes to self-adopted SaaS apps. The bad news is that many of these apps provide virtually no security features or configurable settings that can be hardened. The good news is that this means there is now very little work to do here. When they exist, configuration settings are typically around:

• Forcing the above controls for all users (e.g. force MFA)

• Configuring external or public-sharing settings

Finally, though not mentioned explicitly in the NCSC’s version of the shared-responsibility model, it’s worth remembering that things go wrong even if all the above is in place. That’s where security monitoring comes in. In practice, though, few self-adopted SaaS apps offer audit trails or similar options that can be integrated with SIEM infrastructure. However, you can monitor things like:

• Breached passwords in passwords dumps (think haveibeenpwned.com)

• Typical post-exploitation or persistence techniques (e.g. OAuth integrations or API keys being created, forwarding rules, etc.)

These are the controls that fall into that “easy to understand, easy to recommend, but pretty hard to do at scale” category. Very few organizations have account security controls in place across the bulk of SaaS apps, and especially the apps that were self-adopted. The reality is that most companies still don’t even know about those self-adopted apps. So where should we start?

I think the most sane approach is to avoid speculation and focus on the techniques that are actually being used to attack SaaS apps today. I’ll cut to the chase - it’s credential stuffing we need to prevent. 

Start with preventing credential stuffing

The most common attack against SaaS today is credential stuffing – where attackers use tools that automate the process of taking a list of breached passwords (from public password dumps or traded on underground crime marketplaces) and retargeting those credentials against different apps. 

Slightly more sophisticated attackers might even try expanding their targets by using marketing and advertising services to match private accounts to work accounts in case employees re-used similar passwords. In the example for acme.com in the graphic below, we see how this plays out to get access to a company’s MailChimp. At this point, attackers are able to start sending scam emails to your customers from your domain in emails that look completely legit. This type of attack where compromised SaaS apps are used to send customers malicious emails are something we’ve seen play out a few times recently:

• In this Chipotle attack

• In this DoorDash attack

• In this attack against domain registrar NameCheap

• In this SendGrid attack

• In this MailChimp attack

PLG and the increase in employee-adopted apps has led to employees creating more accounts, on more apps and without the guiding hand of security to make sure strong identity and access controls are in place. 

Opportunistic attackers now have a huge, unmonitored attack surface to target using low effort/cost techniques that generate reliable results for them. 

Why SSO is not the answer to our SaaS account security prayers

Many security teams are leaning on SSO to address this issue. They’ll require that apps used in their company use SSO, specifically SAML (Security Assertion Markup Language) before they can be approved or used. This works really, really well for the apps that provide this functionality. It’s the gold standard for authentication. 

With SAML SSO, there’s just one account, just one password, and you can centrally deprovision accounts when employees leave the organization. In fact, you’re probably already paying for a SAML IdP (Identity Provider) like Google Directory or Azure AD. Many others are using tools like Okta.   

There’s one obvious point we need to make here: SSO isn’t going to help you discover which apps employees are using. But, once you discover them and determine they support SAML, you can integrate them with your solution.

But here lies the problem…when we reviewed 500 of the most popular apps that Push supports, we found that: 

Only around 30% of apps offer SSO and, of those, very few make it available on their lower-priced tiers.

We also noticed that the more modern, newer apps were less likely to offer SAML support than the larger, more established business apps. So if your strategy is to block access to any app that doesn’t offer SSO integrations, you’re going to have to block the majority of self-adopted apps your employees are using. 

There are some other complications and nuances around SAML. Sometimes the SAML integration will only cover one tenant or instance and not the entire app. In this case, every time you find a new workspace or instance, you need to integrate it again. Worse, you can often only integrate one workspace or instance with your SAML IdP. 

Then there’s the ethically dubious issue of “SSO tax” where vendors that do offer SSO reserve it only for their enterprise tiers designed for organizations buying huge volumes of licenses, which makes this impractical for many if not most of us.

A game plan for preventing credential stuffing

I like the idea of going passwordless as much as the next security person, but that’s not practical for many apps right now. So we’re going to rely on passwords as well, at least for the foreseeable future. Strong, unique passwords, coupled with MFA, are very effective identity and access controls, so it’s not the end of the world.

To prevent credential stuffing attacks (and a whole host of other attacks to boot) you will need to implement the following controls:

It’s useful to note from the requirements that you must be in a position to discover SaaS apps being onboarded, but also discover how these apps are accessed.

There’s only one place where we can get data about who is using which SaaS apps, as well as the ability to inspect passwords and check MFA status for each user. And that’s in the employee’s browsers.

This is the reason we have chosen to build our solution using a browser extension. It allows us to:

• Observe username and password logins, 

• Assess their strength and whether they are being shared or reused, and 

• Allow security teams to fix any accounts that don’t meet their policies or expectations.

More on that in a moment, but first, the last piece of advice:

Tackle risk assessment and account security in parallel

Quite often when I talk to security leaders, they’re fixated on supply chain risk and the risk of account compromise is an afterthought. This is understandable - these are the attacks that are widely reported, and require high-level decision making, so this feels like the natural first step. They’re aware that employees are using unvetted apps, but they don’t feel like they’re in a position to secure the employee account until they have identified and vetted all the apps in use. 

It seems logical to want to approve apps first and then secure the accounts. It might make sense if you are starting from zero, however, when organizations get visibility of SaaS apps in use, they usually see hundreds on the list that employees are already using. In this case, waiting to get through the entire backlog of app risk assessment first is counter productive. Regardless of whether an app is approved yet, if it’s in use there is the risk of an attacker compromising a weak employee account with a credential stuffing attack, which is arguably a greater risk than a SaaS vendor being compromised in a supply chain attack. That’s because attacks against employee SaaS accounts are more common, just reported less often than supply chain attacks.

The best way to bring down as much SaaS risk as quickly as possible is to tackle both streams independently and in parallel. But to do this, you need the right tools.  

Push collects usage data from the same place we collect account security data so we can also identify password and MFA data about the employee’s SaaS account. We don’t require you to integrate Push with each app you discover. Instead, usage and security data are collected at the same time we’re discovering the app because we’re using a browser extension. The extension gives us relevant security context so you can address both risks together. On that note, let’s dig into the data that SaaS security tools use.

Choose the right data source

Since we’ve moved from a world in which we as security teams got visibility through process (IT or procurement) to a world where we rely on technology to give us that visibility (for e.g. self-adopted apps) - we’re going to need tooling, and that’s where things get complicated.

The list of SaaS security product categories and tools is growing almost weekly, from Cloud Access Security Broker (CASBs), Security Service Edge (SSEs), SaaS Security Posture Management (SSPMs) and any number of other new buzzwords. The only thing growing faster is the promises they make, so it’s no surprise that it’s very difficult to identify solutions that can actually deliver what’s required.

One critical factor to consider when choosing tooling is the data that these tools build on. The requirements we’ve identified for doing SaaS security in the previous section are that we need to be able to:

• Discover new SaaS apps being adopted (and self-adopted).

• Keep a low rate of false positives, in other words we need to be able to tell the difference between, for example, accessing a SaaS app website or actually login into the app.

• Get insight into the identities or accounts used to access these apps - we need to know which users are authenticating to these apps and how (SSO, Social Logins, Local passwords)

• Identify account security issues such as disabled MFA, weak, reused and breached passwords.

The following is a summary of the most common data sources SaaS security tools are built on, and how they stack up in terms of the requirements above:

Each data source has pros and cons, but let’s take a look at the most common sources to see what the high-level trade-offs are. We’ve got a short blog post on this topic if you want to share with your teammates and peers.

Financial records

Looking through invoices can provide some visibility into paid SaaS apps, which is why it has a very low false positive rate. However, there are blind spots - you won’t see any free tier or trial accounts, nor will you get any useful business context about who’s using it, how they’re using it, if logins are secure, and what data it has access to. That said, it’s a quick and dirty way to get a partial view of SaaS usage and might be the best place to start. 

The main downside of using finance as a data source is that it will discover apps very slowly, most apps will only move to a paid tier once employees have already been using the app for a while on free-tier and have become reliant enough on it that they need additional features or users. This is often too late to steer these users to a different app if there are critical risks identified with the app or vendor.

Email analytics

You can look at all the emails every employee receives and match these emails to different SaaS apps and vendors and based on that information make some statistical guesses about which employees are using which apps. This improves on finance records in a significant metric - speed of detection, but the trade-off is a high rate of false positives. One aspect that email detection is great for that isn’t included in the table is the ability to detect historic SaaS apps.

Unfortunately, except for some very limited edge cases it’s not possible to broadly detect account security issues using email, so at best this is a first-step data source.

Network data

This is the old-school approach that tools like CASBs use to do SaaS discovery, taking data from edge devices like firewalls, proxies, or DNS relays. This makes it very difficult to implement for companies that are distributed and cloud-native. There are now solutions that are more appropriate for distributed teams that work either by collecting network data from the endpoint with an agent, or perhaps your organization is very office-based and has excellent network telemetry - in which case these solutions might be easier to deploy.

While network data is relatively well understood, it’s not a great source for discovering SaaS use (as opposed to detecting when an employee simply accesses SaaS app websites - false positives galore) or for finding account security issues. It’s useful to get an idea of which apps might be used and indications on who might be using the app. But network data doesn’t provide the level of detail needed to discover account security issues. This is why CASB solutions have almost all started including API integrations to augment this data and make it useful - though this has its own problems.

If you’re looking to get a quick outline of which SaaS may be in use, a finance or email-based solution would likely be much easier to deploy and more cost effective. If you want to discover and remediate problems and actually reduce SaaS risk, you need to look elsewhere.

Application API data

Many of the more established SaaS apps (especially those that are almost Platform-as-a-Service or PaaS) like 365, Salesforce, Slack, Github etc. offer APIs that expose security-relevant data. However, for apps that do support these APIs, this is an amazing data source that typically provides the ability to extract user-lists or check account security controls like MFA are enabled for all users, or list third-party integrations. Audit log feeds also provide a useful data source for ingestion into SIEM systems. 

However, APIs as a data source for doing SaaS security has 2 major limitations:

1. No discovery features. You must already know that an app is in use (or more specifically know about every app tenant in use) before you can integrate it with your SaaS security solutions (typically SSPM tools). This means you need some other data source to discover SaaS apps and tenants.

2. Lack of support. These APIs are typically available only for “core” SaaS platforms, and a very small minority of the types of SaaS apps employees might self-adopt will other these security monitoring integrations.

Browser extensions

The idea behind using browser extensions for SaaS security is simple: if all the data you care about monitoring exists in your employees’ browsers, let’s analyze the data in the browser. Browser extensions allow you to deeply inspect users' interactions with SaaS apps. This means you can get close to perfect accuracy in terms of discovering which apps are in-use (vs browser the website) because you can actually observe the login process directly. 

Since you observe the login process with the extension, it’s easy to discover account security issues like weak passwords or missing MFA. You can also tell when employees are logging into apps without using SSO. Best of all you don’t need to create a dragnet and collect all this data centrally creating a privacy nightmare, instead you can analyze this data where it already exists, inside the safe confines of the browser sandbox. The only data you report out is a flag when you find an issue.

Another benefit of browser extensions is that they are not passive. You can easily add active features to extensions that do things like warn users before they even set bad passwords - preventing these issues from occurring in the first place.

The downside is that you need to deploy these browser extensions to employees. This used to be a much bigger issue in the past, but these days it’s easy to deploy extensions to your whole fleet of Chrome, Edge, Firefox, Safari, Brave and Opera browsers using an MDM or GPO policy. Another nice thing about extensions, is that unlike endpoint agents, extensions are cross platform (they don’t care if you are on Windows, Mac or Linux), are isolated to the browser and automatically update through the browser extension store.

I’m sure I’m not doing a great job of hiding my enthusiasm for browser extensions as a platform to build SaaS security tools on, but they truly do provide the kind of fast, accurate and detailed data we need to solve both the supply-chain and customer responsibility sides of SaaS security.

Push uses a browser extension and APIs

That’s why we decided to build Push on a browser extension. To discover and provide security-relevant data about the integrations to your core cloud platforms, we also use APIs. Together, these two data sources provided a full view of the SaaS apps employees are using.

How can Push help?

It probably won’t come as a surprise to find out that we’ve designed Push so security teams can get a handle on employee-adopted SaaS apps without needing to block them.

Here’s a quick rundown of how Push can help you:

Get visibility of shadow SaaS apps and unmanaged cloud accounts

If you’re going to get a handle on employee-adopted SaaS apps, you need to get visibility of them first. Push uses data from our browser extension to find SaaS apps that are logged into with usernames and passwords and SSO (OIDC). This gives you complete visibility of your SaaS environment, including shadow SaaS apps and cloud accounts that are not managed by IT. 

Detect the new apps and integrations employees are adopting in real time

Push detects employees signing up to new apps, or integrating third-party apps to your core work platforms in real-time. That allows you to step in at the earliest opportunity to vet the app for critical issues and guide the employee through the appropriate app onboarding steps. This allows you to focus on the new stuff and buy yourself time as I recommended earlier. 

Avoid wasting time on false-positives

You need to trust your data if you want to take action based on the visibility you have of what apps employees are using and how they’re using them. Doing risk assessments or chasing employees about apps they’re not using wastes time and burns goodwill. 

Throughout this piece I’ve banged on about how critical it is to have the right data. Good data allows you to quickly and accurately identify new SaaS apps and integrations as employees adopt them. Good data is also required to identify the security issues that attackers can exploit to compromise your data through common attacks like Credential Stuffing. The best foundational data to lean on for SaaS visibility and risk is browser extension data.

Push collects data directly from the app using a browser extension, rather than guessing possible use from other sources like network traffic or email. 

That makes Push the only SaaS security solution that can directly observe all SaaS use and the only solution that can identify account security issues across hundreds of apps - completely automatically. No need for API support, no need for an admin account. It just works.

Identify account security risks and discover shadow SaaS at the same time

Supply chain risk is important, but I’d argue account compromise risks are greater for most organizations. Push can identify account security issues that make it possible for attackers to compromise your employees accounts using credential stuffing, brute forcing and phishing attacks. These include:

• Compromised passwords

• Guessable passwords

• Account-sharing between multiple employees

• Sharing passwords across multiple accounts

• Missing MFA

• Password manager use

We identify these issues at the same time we discover shadow SaaS apps, so you can tackle account compromise at the same time as supply chain risk to reduce your SaaS security risk exposure faster.

How do we actually reduce the risks? We engage employees directly via Slack or MS Teams, explain the account security issue we’ve identified in a way they’ll understand, and help them understand how it’s putting them and the business at risk. Then we guide them on how to fix it...

Use Push to secure accounts that aren’t under SSO

In an ideal world, you could stick all your SaaS under your SSO solution, but we’ve already explained why that’s not practical for all apps. For apps and accounts that can’t use SSO, Push makes sure employees are using strong, unique passwords that aren’t published on a password breach list. We’ll also guide employees to use MFA when possible. 

In some instances, we can prevent account security issues from occurring in the first place. When Push detects an employee creating a new account in their browser, we’ll guide them to set up strong identity and access controls on their account, at the first signup...

Get a handle on employee-adopted apps without being a blocker

By using Push, you can have complete visibility of all SaaS apps in your environment, including those adopted by employees without the oversight of IT and Security. We’ll automatically find the security issues that put your data at risk and enlist the support of employees to fix them. This allows you to embrace app self-adoption and adopt a default allow approach that enables your business while scaling security so you don’t lose control of SaaS security risks. 

Push’s free tier gives you 10 licenses for free forever and all the features are baked into that free version. This is a great way to see if it’ll work for you, so jump in and start playing with it!