Want to discover the full extent of your SaaS sprawl? Embrace browser extensions

Security teams know they need full visibility into which SaaS platforms employees are using to even start focusing on SaaS management and security. Even better, they want to understand how employees are using them, right? 

Many people we talk to are starting to chip away at getting visibility into employee-adopted apps by using some combination of central information repositories such as email discovery, financial records, OAuth logs, SSO logs, web proxy logs, etc. So why would anyone want or need to use a browser extension? Browser extensions are the most effective SaaS discovery tool because they can capture employee SaaS use and adoption in real time, as employees sign up. The browser also allows us to work with the user to guide them to use SaaS more securely right where they’re working - in the browser.

We’ll dig into this topic a bit more in this article and we’d love to hear questions, concerns, and have a healthy debate on our social media channels, so hit us up!

Introduction

Different approaches for discovering SaaS use have unique advantages and disadvantages and the most effective solution is usually to combine several approaches that complement one another. That being said, in the case of SaaS discovery, browser extensions have some really significant advantages that can’t be matched by other approaches - so if you could only pick one approach, then a browser extension is the way to go.

The first point to consider is that it is extremely common for SaaS solutions to be self-adopted by individual employees or teams within a business, without working with IT or following the established procurement process. According to G2, 80% of workers admit to using SaaS applications at work without getting approval from IT. Employees are likely to access SaaS however is easiest and most familiar for them. So, employees aren’t going to set up a full SSO connection with your own authentication provider (on the off chance that the app even provides SSO integration). They might not be using a social login using your M365/Google tenant and they might not even be using their company email to sign up/login - they could just be using a personal webmail account.

That leaves security teams with limited or no visibility of employee SaaS use using other centralized methods. We found that only around 30% of SaaS providers we analyzed support SSO and of those that do, many require paying for the highest cost enterprise plan in order to gain access to it - i.e. “The SSO tax.” 

Many don’t support social logins and, if they do, you’ll find M365 social logins are much less commonly supported than Google, so if you’re a Microsoft house, that pushes users towards individual email/password logins, which are far less secure.

A comparison of data sources for SaaS discovery

We won’t do a deep dive of comparing data sources for SaaS discovery in this post, but here’s a quick and dirty overview. As we mentioned above, most companies (and off-the-shelf SaaS security and SaaS management tools) use some combination of the data sources depicted in the image below. 

 Now, it goes without saying that we’re a bit biased, but as we were deciding how to build our own SaaS discovery methods, we analyzed the pros and cons of each of these approaches before realizing that the most power was in the browser. Ease of deployment, you’ll notice, takes a bit more work than a couple other methods, but it’s worth it once you realize the powerful capabilities uniquely available in the browser. We’ll address the deployment and rollout challenges in a bit more detail later in this post. 

To dig into each of these approaches and how to potentially combine them to build your own SaaS discovery engine, check out this post. 

If you already know you don’t have the resources (time, team, budget) to build your own and you’re thinking about evaluating solutions, head over to this post to understand which might be the best fit for your company. 

Next, we’ll dig into how we manage our own SaaS security to provide some relevant context and we’ll explain where the browser extension fits in

A case study…with us!

To put this into context, we’ll use ourselves as an example, since we’re a fully SaaS-native company. Our entire business is SaaS security, we have no physical or virtual infrastructure to manage and we actively encourage our employees to self-adopt SaaS solutions to solve their own business needs. We’re also a Google workspace enterprise customer and we educate our employees to always use Google social logins for SaaS solutions as the first choice when available ). 

We tuck all SaaS apps behind SSO, wherever we can and wherever our licenses will let us. And since we’re a fairly new company, we’ve been able to push social logins and “login with Google” to our employees since day one, so that’s a pretty clean and ideal world compared to the environments many security folks are working in. This means we really should be a best case example when it comes to centralized SaaS discovery methods. That said, we also use almost 100 different SaaS platforms across the company and, despite everything else above, 33% of these SaaS platforms are only visible because we’re using a browser extension to discover them as our employees sign up.

A similar company without a browser extension could be missing out on a third of their SaaS platforms. Once we look at similar stats for our customers, particularly M365 users, we see the percentage of SaaS platforms that are only discovered via the browser extension increase and this is sometimes even as high as 70-80%. If you’re serious about SaaS discovery, then you should really not settle for missing such a large percentage of platforms.

Why does a browser see so much more?

Since SaaS is often self-adopted, the problem can often be attributed to a decentralized problem. Many SaaS vendors even encourage this as they have a product-led growth (PLG) model and prefer the frictionless growth of a PLG model over the high-friction sales cycle in a centralized procurement model. We’ve got a webinar with our co-founder on this topic if you want to explore further. 

Additionally, your average non-technical employee may not be familiar with SSO or social logins as access methods, but everyone knows how to sign-up for a website with an email address, username and password. Consequently, it’s just common for centralized data sources to end up missing a lot of SaaS use if they’re looking at logs, proxies, and other data sources.

Without SSO or social logins, you aren’t seeing anything via those data sources. If you use email discovery, you’ll have lots of false positives to deal with from marketing spam and you’ll only know about it for employees that used their corporate email address and for SaaS platforms that actively send out emails. If you’re relying on network data sources like web proxy data then you need to be capturing everything including home/mobile employees and even then most details will be hidden behind HTTPS connections. You could intercept and decrypt all HTTPS traffic via your proxy, but then you’d be introducing a huge security risk by decrypting all communications in one place. We’ve got a more thorough article on the topic of SaaS discovery data sources and their pros and cons to read up on, too. 

On the other hand, browsers are quickly becoming the main way people operate from a desktop environment, with the browser as the way they’re doing almost every task. Since they’re using the browser to access their apps, it makes sense to use data collected from the browser to get visibility of SaaS. It doesn’t matter if they use an SSO login, a social login, an email address/password login, a corporate email or a personal webmail account - as long as they login or access the SaaS platform from a browser, then a browser extension is best placed to see that. Wherever the user is in the world, whatever they are doing, the extension can keep an eye out.

There are so many other security benefits beyond basic visibility

We’ve covered general visibility of SaaS platforms (i.e. whether they are in use or not, what login method is in use and by who), but there’s much more useful information for managing SaaS security risks. To secure SaaS, you also need to know whether multi-factor authentication (MFA) is in use; If the password is secure; If passwords are shared between different accounts; If accounts are shared between users; If sensitive files are uploaded to a particular SaaS platform.

Some SaaS vendors may provide APIs and logs that can answer some of these questions, but this tends to be limited to the biggest or most security conscious vendors. It’s overwhelming to handle this manually because you need to consider separate integrations with all your different SaaS vendors, and that’s assuming you already know they are in use. It might be viable for some of the most important SaaS platforms you use (think Salesforce, Slack, Trello, etc.) , but it’s not easy to go much further when you have hundreds of different SaaS platforms to consider.

A browser extension, on the other hand, can see all the interactions between users and any given SaaS platform, so it can provide insights that may not be visible via a SaaS vendor’s own APIs or logs. This is especially true for fairly standardized mechanisms such as web-based logins, where it provides an easy opportunity to provide password security checks and MFA checks. 

Being a decentralized model, this can all be achieved without sending lots of highly sensitive data (e.g. passwords) to a centralized point. Instead, the browser extension can just report individual security findings as necessary without feeding that private data to a central repository. The Push browser extension identifies weak passwords in use, MFA status, passwords shared between different SaaS platforms and even accounts being shared by multiple different users - none of this requires sending passwords or any other sensitive data to our central servers - just the findings themselves. You can find more information about what data we collect here. 

How do I roll out a browser extension to every single employee?

Traditionally, browser extensions have been focused on self-adoption by users via a browser extension store. In that case, the user makes the decision to install, rather than IT or security managing the deployment.

However, the major browser vendors have made it easy to install and manage browser extensions centrally, as well as making them more resilient to ensure they’re both secure and cannot induce significant performance issues in the browser.

Most larger organizations will be familiar with deploying desktop software remotely using central device management software, especially for endpoint security software like anti-virus and EDR. The same idea works with a browser extension using most of the common browser and operating system combinations. The Push browser extension can be deployed centrally on Chrome, Edge, Firefox and Brave, depending on the device management software and operating system in use.

What’s more, browser extensions consist of JavaScript running in a tightly-controlled environment with additional performance controls in place by the browser and they even auto-update too. Compare this with the common case for endpoint security software of having an agent running as SYSTEM/root and users complaining it’s stealing all their CPU cycles and centralized browser deployment starts looking like a more attractive prospect than traditional endpoint agent deployment.

Conclusion

We’re pretty into browser extensions here, but it’s not just because that’s how our product works. We’re not trying to sell you a new thing just for the sake of building something novel. Browser extensions are going to become one of the most important methods of managing SaaS security going forward. They’ve got advantages that other approaches just can’t match and centralized deployment and management is now a slick, easy and - frankly - solved problem. We get why you might not believe us yet, but we invite you to try our extension for free, so you can argue with us on our Twitter and LinkedIn.