SaaS sprawl isn't a problem - if you completely change your approach

Introduction

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

Now it's the first. 

SaaS vendors bypass IT and security and hook employees with free apps and trials. This has led to sensitive data on shadow SaaS applications (more on this later) that is accessible via unmanaged cloud accounts (accounts that aren’t protected by SSO or logged into via social login accounts). Attackers exploit this unmonitored attack surface with new takes on old techniques that are going undetected.

Employees self-adopting apps might sound like a security nightmare, but it doesn’t have to be. In fact, it can be a really good thing that enables employees to be more productive and your business to be more competitive. And, frankly, there’s no way to stop it without causing a SaaS sprawl issue. 

What’s clear is that this new landscape has fundamentally changed the way 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.

Security teams need to regain visibility and control over company data and how it’s secured. 

In this guide I’ll show security teams: 

• What’s driving employee app self-adoption and the impact on security teams

• Why the go-to solutions of policies and tools that block access to unsanctioned apps don’t work

• What new approaches can work and how to apply them

• The two aspects to address when securing SaaS and managing risk 

At the end of this book, we’ll link to a guide filled with practical guidance on how to manage those risks and quickly reduce your risk exposure. In that guide, we’ll also cover which data sources are available for SaaS security and why the choice is crucial.

The guidance provided here has been developed after talking with security leaders and CISOs that are already successfully embracing SaaS self-adoption while keeping a handle on risks. There are too many folks here to thank personally, but if you recognize some of this from our discussions, please accept my thanks, and hopefully there’s something new and useful here for you as well!

Why is it so easy for employees to self-adopt new apps without IT?

Memories of a simpler time

Before cloud computing was a thing, IT teams procured and managed hardware, software, networks and services for their businesses. The business was dependent on IT deploying new software across their on-prem network and managing it, so it was nearly impossible to bypass them. They became, in effect, the gatekeepers to the business’ IT environment. The onboarding process typically looked something like this:

IT asked Security to review a new app and its vendor to identify risks and determine if it should be adopted. At this point, security would specify which controls were required for it to be used securely. This all happened  before an app touched their network and interacted with any live data.

In return, Security could rely on IT to give them accurate information about all the businesses’ technology assets that needed to be protected. This process gave both teams great visibility across their total IT environment. Security and IT could maintain a high degree of control over how technology was used. 

In other words, life was wonderful and no one ever got hacked (maybe, it’s hard to remember now). Then the cloud happened and ruined everything.

Clearly I’m joking, but while very few orgs got it perfect, it was “good enough” at providing process-driven visibility of what enterprise software was being deployed for most.

The birth of the “as-a-Service” era

I jest, the cloud hasn’t ruined everything. It gave organizations the opportunity to be faster, more flexible and more efficient. Businesses no longer had to buy and manage all their own infrastructure and apps, they could just pay for what they used when they needed it. It led to a wave of “as-a-service” business models that stretched across infrastructure, platforms and software. 

Thousands of new software-as-a-service (SaaS) companies emerged with high quality apps that were easy to use over the internet. Essentially SaaS created software employees could use on-demand, which was a huge departure from the old days when IT and Security would do loads of security vetting upfront because they knew they’d be stuck with the software for years after deploying.

Leveraging great on-demand software tools boosted employee productivity and made their businesses more competitive. Tech-savvy employees, used to subscribing to on-demand software services in their personal lives, started to demand more autonomy over the technology they use at work. They were no longer satisfied with the generic suite of programs that IT could provide for them. Instead, they wanted the specialist tools designed and built for people like them by people like them. 

Despite users loving the software once they tried it, SaaS vendors were struggling to sell into large organizations with complicated procurement processes - it was too difficult to get their software in user's hands, and got more difficult the more niche and specialized the app was.

The rise of Product-Led Growth

Enter Wes Bush, a young SaaS marketer who published his book Product Led Growth in 2019. In it, he showed SaaS vendors how they can increase their sales revenues while reducing their sales cycles and costs by using their products as their primary go-to-market vehicle, as opposed to traditional sales teams. 

The premise is simple; prospective customers prefer to experience the value of a product rather than be told about it by sales people. Back in 2015 Forrester reported that 75% of B2B buyers prefer a sales-rep-free buying process. The book became a phenomenon within the SaaS industry. Product-led growth (PLG) is now the norm for SaaS companies, and around 60% of SaaS companies now use PLG and that’s only going to increase.

Why is PLG turning software adoption on its head? In order to establish a PLG go-to-market motion, SaaS vendors need end users to try their product, either as a free trial or a free version of the app, and quickly experience value from it so  they’re motivated to champion the internal business case through to a successful purchase. 

PLG not only relies upon end users as the initial adopters of a new app, but for them to experience meaningful value during that initial experience. This nearly always necessitates that the new app interacts with real data in a live environment. What’s more, it’s only the apps that end users want to use in a paid tier that are likely to ever get submitted to the app-onboarding process. The freemium and trial versions of apps that are just tried out are unlikely to ever be presented to IT and security. 

This obviously poses a problem from an IT and security standpoint.

SaaS vendors are deliberately bypassing the traditional software procurement processes that used to give IT and security teams visibility of the third party apps that had their data. 

Instead, SaaS vendors are directly targeting employees with their apps and encouraging them to plug them straight into live environments before they’ve been vetted. Software onboarding now looks a lot more like this:

IT and security teams might be the last to know about PLG and miss the scale of the change

IT & security folks are usually ahead of the curve when it comes to technology shifts, but in this case many might have missed the scale or speed of the change. That’s because IT and security tools are among the least product-led of any sector. Most of our industry’s tools require heavy integrations, complicated setup, agent deployments, and so on. 

Unfortunately, few security companies are making products as easy to set up and use as new tools for marketing, sales, finance, development, engineering design, legal, HR, and basically every other sector that can’t rely on a technical first user. 

This leads to a misconception in IT and Security teams that self-adopted apps are fringe and don’t contain significant sensitive data.

Most concerning for security teams is that the sheer number of apps in use has increased dramatically and will continue to do so. There are a couple reasons for this: 

1. The big old monolithic on-prem software is being replaced not by a single SaaS app, but an ecosystem of specialized apps. Each new app integrates and extends the functionality as the team using the stack learns what they need, so there is a one-to-many shift happening. 

2. Since apps are virtually zero-maintenance these days, the operating cost (if not the licensing cost) of running multiple apps is almost the same as one (compared to on-prem apps), so duplicate apps are far less of a problem. This also makes them pretty common and further multiplies the number of apps and vendors.

The impact of self-adoption on security

Loss of visibility

We’ve seen how SaaS vendors' move to PLG has led to greater employee self-adoption of work apps that don’t require IT or Security to be involved. The direct consequence of this is that Security teams have lost process-driven visibility of their company’s SaaS estate. This problem is often called “Shadow SaaS.” It is 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. 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 is very little Security can do that will convince them to move to a more secure app, or for multiple teams to use a single app. Typically, this intervention from Security needs to happen very early - long before finance is involved - in order to make a positive impact. 

Incident Response is necessary, of course, when a SaaS account is breached (or an ex-employee SaaS account that was never properly offboarded), but cannot recover the lost data after the proverbial horse has bolted. It’s now possible to get into the process early, so security teams can get ahead of the problem to reduce the risk.

Another situation that is increasingly pressing, and difficult for security teams to deal with is the increasingly regular: “App X has just had a major breach, are we using AppX, is any of our data there?” It’s an embarrassing situation to not be able to answer these questions.

Core problem

Once teams get visibility into the scope of the Shadow SaaS and sprawl problem, they find that Security no longer dictates the pace of adoption. They’re also typically surprised by the sheer volume of apps employees have adopted. A report from Ascendix claims that “by the end of 2023, there will be anywhere from 30,000-72,000 SaaS companies in operation.” Clearly these aren’t all work apps or hyper specialized, but there should be no doubt that we aren’t talking about a few dozen apps being adopted.

Once teams get visibility of the pace that news apps are added they realize they need to risk assess 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. None of these are pleasant options.

Temptation to revert to the old ways of block-first

When the idea of the options above proves daunting or impossible, Security often tries to revert to the old process - 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. Cloud Access Security Brokers (CASBs) were built to do exactly this - help security teams control (and block) access to “unsanctioned” SaaS that IT hasn’t approved (incidentally I think this explains why the CASB segment has failed). 

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. 

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.

Surely there’s a better way

Of course we think there’s a better way, or we wouldn’t have written this. And don’t call me Shirley. 

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. Stop asking employees to adapt to fit our legacy processes and meet them halfway. Security can no longer be a gate with a default stance of “No, until.” Instead Security needs to be a business enablement partner that says “Yes, unless.”

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.” I understand this is deeply uncomfortable for many security practitioners (as it still is for me), but let me explain why I think this leads to a better long-term outcome.

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. SaaS apps aren’t forever - quite the opposite! Apps aren’t just unused and not-adopted and then suddenly fully-adopted. 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 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. Luckily, many apps employees are using might ultimately be very low risk, so not every app will require a full security vetting like you would have done in the old-school process.

Our role as Security 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 the key thing is that Security needs to get involved early in the adoption process. For more practical guidance on how to adapt to this new landscape, read our guide Protect your data across your apps…even the ones employees adopt without you knowing.

I’m getting into the details now - so this feels like a good time to take a step back and think about the elements that make up a SaaS security program.

What’s a good SaaS security program?

The shared-responsibility model between cloud platforms and their customers is a great place to start, as it helps customers understand what their responsibilities are, and which responsibilities they’re delegating to their cloud provider.

Delegate to the cloud provider when you can 

It’s generally preferable to delegate as much responsibility as possible to the cloud provider, so it’s no surprise that the SaaS model is the most common and fastest growing sector.

The following summary table produced by the National Cyber Security Centre (NCSC) does a great job at showing 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:

According to NCSC, the customer is responsible only for:

1. The configuration of the SaaS app and 

2. Making sure that the identity and access control features provided by the vendor are used properly.

It’s worth pointing out here that the way application configuration is presented here is a bit of a red herring. The vast majority of SaaS apps (and especially self-adopted apps) allow very little, if any, 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.  As far as configuration is concerned, Security teams will often be limited to enabling “force MFA for all users” or “disallow public sharing” type of controls that are accessible even to non-technical users.

For the vast majority of apps in the organization, Security’s responsibility will boil down to:

• Account security, i.e. making sure MFA and SSO (where available) is in place. 

• Ensuring  employees are using strong passwords, especially if MFA and/or SSO aren’t available.

• Removing external accounts (and accounts for those that have left the company) when no longer needed.

Isn’t it risky to delegate responsibility? While delegating security responsibilities is great and takes a huge load off your team, we do, unfortunately, need to consider who we’re delegating it to. Those gray boxes in the diagram above need to be taken care of.

This is what’s sometimes understood as “supply chain” security. You need to trust the SaaS vendor 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 and in practice many SaaS vendors do a great job, with many providing easy-to-audit, externally-verified, policies through a framework such as SOC2, and most do regular penetration tests and have bug bounty programs etc.

There are exceptions when it makes sense to think more carefully about whether a third party can be trusted. Common reasons Push customers have cited for not trusting third parties include; 

• The data going into these apps is simply too high risk. Many organizations have very sensitive customer information or intellectual property that they simply aren’t willing to entrust to a third party. Many don’t trust a third party with administrative access to the systems where this data is held.

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

• Vendors who’ve had 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. Consider the string of breaches at LastPass, Okta, Twilio (and many others) or as a typical example of this.

• Products that don’t offer adequate security features. Customers expect features such as MFA, SSO (either social login through OIDC or, ideally, SAML), and the ability to enforce these controls. This is especially important on platforms where the data is high-risk.

• The vendor operates in a sanctioned country or may not have the resources to adequately protect your data. Clearly vendors operating from (or that have close ties with) sanctioned or politically-complicated countries represent additional risk, as do vendors that are “one man bands” or are so small that it is hard to imagine they can afford to spend significant resources on security.

The two questions you need to ask to assess risk 

The essence of the shared-responsibility model can summarized as two questions:

1. Should we be using this app?

2. Are we using it securely?

A successful SaaS security program must address both these questions. We can’t spend all our time doing risk assessments and due diligence exercises on our supply chain while dropping the ball on account security. Similarly, we can’t just focus on making sure all accounts have MFA in place when the vendor is leaving the back door open.

When shared responsibility goes wrong

The following is an extract of some well-covered recent(ish) breaches of SaaS companies. As we go through it, pay attention to which side is dropping the ball in terms of the shared responsibility. The same organization can be:

• the source of a breach, 

• the ultimate target that motivated a breach at a partner that was a softer target, 

• or simply the unlucky victim of a breach further down its supply chain.

That’s the thing about supply chain attacks, organizations are the attacker’s stepping stones. Where they are in the attack chain determines how we label their victims. 

This is a very shallow summary of a small sample of events during this time frame, but it’s interesting how interrelated these SaaS services are. Many are part of each other’s supply chains (for example, Twilio is targeted as an Okta customer itself, and used to compromise Okta customer MFA codes that are delivered by Twilio to other Okta customers) and so breaches in one SaaS have rippling effects that sometimes take months or even years to materialize after a breach occurs.

There’s an interesting trend to call out here: breaches at a SaaS vendor appear to lead to (or correlate with) further breaches, such as the string of breaches at LastPass. But it’s incredibly unclear how to balance the risk of using these vendors, especially when some of these companies (like Okta) are a big part of many organization’s security strategies.

Ultimately, though… 

The root of most of these networks of supply chain attacks are simple account compromises. 

While most organizations think of the supply chain aspect (should we be using this app?) as the majority of the problem, or at least the first problem to solve - account security is ultimately at the heart of the problem. A developer or support engineer with a weak password or missing MFA is all it takes for them to get phished, kicking off this string of attacks. Unlike the complex supply chain risk questions, account security issues are straightforward to fix. We’d be a whole lot closer to securing the whole supply chain if we could improve account security for all employees across all the SaaS apps they use. 

Where do we go from here?

So we’ve discussed the domino-like string of effects from SaaS sales, to PLG, to self-adoption, to shadow SaaS, to growing SaaS risks and the news stories we read about.

We’ve unpacked the shared responsibility model - and I hope I’ve convinced you that we need to look at both the supply chain and account security side equally (and in parallel!) to manage this risk. What I haven’t done is describe how to do this practically, because this ebook was getting a bit of a weighty tome, we split that out into part 2.

In our next ebook: The no-jargon guide to solving shadow SaaS, we’ll give you practical first steps to get a handle on employee-adopted SaaS apps. 

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 attack.

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