As you may have noticed on your recent Zoom calls, the latest application update quietly added a slick little app-store sidebar to the right-hand side of your session screen. This feature enables any business user within your organization to integrate the software-as-a-service (SaaS) apps showcased in the sidebar with a click of a button — without so much as disrupting their Zoom session.
While seemingly innocuous, this feature highlights the greatest strength and one of the greatest SaaS security risks — the ability for anyone within an organization to adopt, configure, and manage SaaS applications. While this process may be convenient and conducive to fast business enablement, by design it also bypasses any internal security review processes. This leaves your security team with no means of knowing which apps are being adopted and used, whether they may have security vulnerabilities, if they are being used in a secure way, or how to place security guardrails around their use. Enforcing zero-trust security principles becomes almost impossible.
But before you chastise your employees for irresponsibly adopting SaaS applications, you need to realize they're being constantly encouraged by vendors to install more apps and adopt new features. Yes, the applications themselves often serve critical business needs, and yes, your employees inherently want to adopt them quickly, without enduring a protracted security review. Yet, they're doing so because — whether they realize it or not — they're being aggressively marketed to by savvy application vendors, who often mislead users into believing they're following security best practices. Just because users are bombarded during installation with consent screens meant to give them pause and encourage them to read about their rights and responsibilities doesn’t mean users are actually reading these screens, or that the consent language is transparent, accurate, or complete.
Beyond touting their application's brilliant new features, these vendors are also constantly telling your business users and security teams their applications are secure, their infrastructure is secure, that 24/7 uptime is 99.999% assured, and they guarantee that their employees won’t have access to user's data, etc. However, they typically downplay or even fail to mention their shared responsibility model of security, where they're only responsible for the security of the platform infrastructure, and that securing usage against account takeovers and data loss are the customer's responsibility.
This is especially problematic as most security breaches are due to SaaS misconfiguration or user error, not code vulnerabilities, and your users are ill-equipped to defend against these risks by themselves. Even large and respectable vendors such as GitHub, HubSpot, LastPass, Mailchimp, Okta, and others that were recently victims of breaches, are susceptible to misconfigurations and misuse. You should always trust, but verify no matter the vendor.
In other cases, security is often just assumed. Take application marketplaces operated by well-known brands, for example. Vendors have neither the desire, nor the financial incentive or capacity, to vet the security posture of every third-party application being sold on their marketplaces. Yet to grow the business they can lead users to believe that anything sold there maintains the same level of security that the marketplace vendor does, often by omission. Likewise, marketplace descriptions may be written in such a way as to imply their application was developed in collaboration with or endorsed by a major, secure brand.
The use of application marketplaces creates third-party integrations that carry the same risks as those that led to many of the recent attacks. During the GitHub attack campaign in April 2022, attackers were able to steal and abuse legitimate Heroku and Travis-CI OAuth tokens issued to the well-known vendors. According to GitHub, the attackers were able to leverage the trust and high access granted to reputed vendors to steal data from dozens of GitHub customers and private repositories.
Similarly in December 2022, CircleCI, a vendor specializing in CI/CD and DevOps tools, confirmed some customer data was stolen in a data breach. The trigger to the investigation was a compromised GitHub OAuth token. Based on the investigation by the CircleCI team, the attackers were able to steal a valid session token of a CircleCI engineer, which allowed them to bypass the two-factor authentication protection and gain unauthorized access to production systems. They were then able to steal customer variables, tokens, and keys.
Lure of Frictionless Adoption
Vendors also build their platforms and incentive programs to make adoption as easy as agreeing to a free trial, a perpetual free service tier, or swiping a credit card, often with seductive discounts to try and buy without obligation.
It's in the interest of the vendors to get users hooked quickly on any cool, new functionality by removing all friction to adoption, including bypassing IT and security team reviews in the process. The hope is that even if security teams grow wise to the use of an application, it will prove too popular with business users and too critical to business operations to remove it. However, making adoption overly easy can also lead to a proliferation of unused, abandoned, and exposed apps. Once an app is rejected during a proof of concept (PoC), is abandoned due to waning interest, or the app owner leaves the organization, it can often remain active, providing an expanded and unguarded attack surface that places the organization and data at elevated risk.
While it's important to educate your business users on SaaS security best practices, it's even more important to fight indiscriminate SaaS sprawl by teaching them to evaluate more critically the siren song of SaaS vendors about easy deployment and financial incentives.
Further, security teams should also adopt tools that can assist in managing SaaS misconfiguration risks and SaaS-to-SaaS integrations. These tools enable users to continue to adopt SaaS applications as needed while still vetting new vendors and integrations for security and establishing much-needed security guardrails.