7 Steps to secure your data across shadow SaaS apps

Employees using a new work SaaS application used to be the final step of the software-onboarding process. 

Now it's the first. 

SaaS providers bypass IT and security and hook employees with free apps and trials. This has led to sensitive data on shadow SaaS applications that’s accessible via unmanaged cloud accounts – all those accounts that aren’t protected by SSO or logged into via social login accounts. This leads to security threats because attackers know SaaS is a blind spot for most organizations.

Attackers exploit this unmonitored attack surface with new takes on old techniques that are going undetected.

We’ve gone from this:

To this: 

Security is now coming in at the end of their old software procurement process and needs to figure out how to regain control of their data. 

You don’t want to stop employees from adopting SaaS apps… 

Employees self-adopting SaaS platforms might sound like a security nightmare, but it doesn’t have to be. This actually enables employees to be more productive and your business to be more competitive. 

This new landscape has fundamentally changed how software is brought into the business. The days of security acting as a gatekeeper that all apps must pass through before they can touch live data are over. The market forces driving self-service apps aren’t stopping, so the security industry needs to adapt.

What’s the impact of self-adoption on security?

Loss of visibility

Most SaaS providers have moved to the product-led growth (PLG) model as the fastest and easiest way to get users for their apps. They want employees to start using SaaS without going through IT and security teams’ lengthy approval processes. We’ve written much more about this in this ebook (ungated and free to download). This SaaS vendor sales model has had a massive impact on security and introduced SaaS security risks, but most security teams are unaware of the scale and scope of the problem because they can’t get necessary visibility into all the tools and apps their employees are using.

Shadow SaaS

This problem is often called “Shadow SaaS” and it’s also the first problem to solve -  the old adage “you can’t secure what you don’t know about” is as true in the SaaS world as it is in any other security domain.

The lack of visibility means many IT and security teams missed the explosion of SaaS apps, plugins, extensions, and integrations that make up the modern IT stack. More crucially, they’ve missed the movement of company data into these apps. 

SaaS Sprawl

Complicating matters further, many of these apps are duplicate, abandoned or unmanaged - an issue often called “SaaS sprawl.”

Increasing incidents and impacts

Though security teams have lost direct visibility, they’ve not lost complete visibility and many are finding out about at least a fraction of these apps - typically by working with finance teams once employees want apps to go from free-tier to licensed plans. And all too often, security teams find out about shadow SaaS apps in the worst way possible - when something has already gone wrong and security is asked to respond to an incident on a SaaS platform.

In both cases, Security is getting visibility too late to be of much value. Once a team has been using an app (even on a free tier) for a year, there’s not much Security can do that will convince employees/teams to move to a more secure app. 

To change that, Security needs to intervene and get involved very early in the app adoption process - long before finance is involved. 

Incident Response is necessary, of course, when a SaaS account is breached, but can’t recover the lost data after attackers have had access to it. 

Holy S*it - there are so many apps!

Once teams get visibility into the scope of the Shadow SaaS and sprawl problem, they’re usually surprised by the sheer volume of apps employees have adopted. Then they realize they need to do risk assessments on dozens of apps a month instead of the dozen a year that were going through IT in the old, managed and controlled process. To deal with this massive influx of new apps, security teams feel they must either radically increase the headcount, cut corners or drastically increase acceptable risk levels for data security. Neither of these are great options.

This is why SSPMs and CASBs exist, right?

SaaS Security Posture Management (SSPMs) and Cloud Access Security Brokers (CASBs) are the most common categories of solutions meant to attack this visibility blindspot issue, but none of these tools are getting the full picture of the problem. 

At best, they simply chip away at the problem and make security feel like they’ve got a handle on employee-adopted SaaS. At worst, they give a false sense of security while only actually covering a small portion of the SaaS apps where business data actually lives. 

The key thing to consider about any of these solutions is what data sources they’re using to collect (typically network data, financial records, email data, application or endpoint data). We won’t dig into the full list of pros and cons of these types of tools, but we encourage you to read about them more here. 

SSPM tools typically don’t do SaaS discovery - they don’t find apps employees log into, but they do tackle the application hardening and monitoring problem because they focus on policy enforcement and log-monitoring through APIs. 

Both SSPMs and CASBs make sense logically as a way to regain control of the situation. But we’d like to challenge the thinking that regaining control has to mean enforcing rigid security policies and restricting app access. 

Adjust your thinking to secure SaaS

Resist the temptation to revert to the old ways 

When the idea of the options above proves daunting or impossible, Security often tries to revert to the old process - putting security measures in place to regain the ability to set the pace of adoption by re-establishing the gate. 

Practically, this means that you’re deploying technical controls to try block all SaaS apps until they are approved (and marked as allowed) by IT or Security. Technically, this makes total sense. But the unforeseen consequence is that it positions Security as blockers (aka the “Department of No”) and puts them at odds with the rest of the business, rather than working towards a shared goal. 

Why being the “Department of No” doesn’t work 

This block-everything-until-security-approves-it position requires incredible executive support to maintain. For all but the most risk-sensitive organizations (read .gov), this position also normalizes employee behavior to bypass Security in favor of working quickly and effectively. 

In the end, Security actually loses visibility into employee SaaS use and effectively loses control, rather than locking it down. On behalf of all the employees out there, I want to make a point to say employees aren’t trying to break rules Security put in place, they’re just trying to get their jobs done, and might try and find ways around things they see as unreasonably slowing them down or preventing them from reaching their targets. Seen in this light, it’s no surprise that:

• If you block websites, employees bypass network controls, 

• if you block social logins, employees use passwords, 

• if you stop them using work devices to sign up to apps, they use personal devices.

Each blocking action leads to a worse security outcome and blinds the security team further - losing control rather than regaining it.

You can attempt to delay this process by blocking, or you can adapt.

Don’t worry, there’s a better way, but you must adapt your thinking

The first thing we need to do as an industry is agree that we don’t want to be the blockers. We don’t want to stop employees from self-adopting apps. We understand they are best placed to find and select the tools that are going to allow them to be more productive and help your company succeed. 

We need to:

• embrace SaaS app self-adoption, and 

• stop asking employees to adapt to fit our legacy processes. 

Security can no longer be a gate with a default stance of “No, until.” Instead Security needs to be a partner that says “Yes, unless.”

From the “Department of No” to the “Department of Yes, Unless?”

To adapt to this new SaaS-first world, security must move from saying “No, until we’ve had time to fully vet and onboard this app officially” to “Yes! You can use that app, unless we quickly identify security risks that outweigh the value of the tool.”

We know this is deeply uncomfortable for many security practitioners, but it will lead to a better long-term outcome.

How to regain control of the SaaS explosion

Step 1: Understand how employees typically test drive and eventually adopt SaaS

Obviously, self-adoption of SaaS is fundamentally different to IT/Security adopted and managed from a risk perspective. With SaaS, there’s no giant commitment upfront. Apps don’t (usually) just go from unknown and unused to adopted in a day. Just like adopting software was a process for Security and IT back in the day, employees follow a (less rigid) process with SaaS - from testing > to using > to finding value > to inviting teammates, etc. 

The risk grows as we proceed through the adoption process as employees add more data into the app and integrate it with other apps. The workflow below outlines a fairly typical SaaS testing and adopting process for employees:

Step 2: Get involved early to have a real security impact

The upside for Security is that because SaaS adoption is a process over time, we can use that time to assess the risk of the app before it’s fully adopted, as long as we know about the app from the start. 

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). Security can focus their efforts on these high-risk vendors and apps to make sure they can be trusted with their data. 

But this is key: Security needs to get involved early in the adoption process. 

Step 3: Get real-time visibility into SaaS apps and risks as employees sign up for them

You guessed it - Push can help!

We detect employees signing up to new apps and 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. 

Step 4: 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. 

Good data allows you to:

• Quickly and accurately identify new SaaS apps and integrations as employees adopt them. 

• Identify the security issues that attackers can exploit to compromise your data through common attacks like Credential Stuffing. 

Step 5: Use Browser extension data to get the most accurate and useful data for SaaS visibility and risk 

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. For all your SaaS.

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

Of course you need to start by discovering SaaS and getting a reliable inventory - but this on its own won’t stop accounts on those apps from getting breached. The most common way SaaS accounts are breached is through attacks like credential stuffing that target weak, breached or shared passwords on accounts that don’t have MFA enabled. 

Push can identify account security issues to prevent these common 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 SaaS discovery to reduce your SaaS security risk exposure faster.

Step 7: Automatically reduce the risks we find by engaging employees

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.

More resources to explore

For more practical guidance on how to adapt to this new landscape (even if you decide not to use Push as your solution), read Protect your data across all your apps…even the ones employees use without you knowing.

Also, have a listen to our co-founder, former Red Teamer, and CPO Jacques Louw talk about this new SaaS attack landscape. He’ll share additional practical guidance beyond the necessary shift in security’s thinking we’ve discussed here, including when security needs to get involved in this new software procurement process to make the biggest positive impact to securing sensitive data across all third-party vendors, apps, and suppliers.