Software as a service (SaaS) has taken over, and the average enterprise now uses hundreds of unique SaaS applications to accelerate their digital transformation and business velocity. Though it was already on the rise, the global pandemic and widespread Work From Home (WFH) policies dramatically accelerated enterprise dependence on SaaS across every market sector—even traditional laggards like health and finance. 

However, while SaaS has fulfilled its growth-enabling potential, most organizations have lost their grip on its consumption and use. SaaS is internet accessible, and IT and security teams can no longer depend on network or endpoint controls to govern application access. In other words, traditional security teams are left blind to actual activity. The only way forward is to keep updated on all SaaS-related technological developments as they happen. However, is that realistic for already swamped IT and security managers?

The rise of the SaaS Sprawl?

Unlike traditional, on-prem third-party software, SaaS applications users can bypass IT review, approval and installation. Steeping security leaders in darkness, this is the origin of the SaaS sprawl. The sprawl is dangerous; Despite often holding sensitive information, many of the applications within it lack the bare minimum of security features of sanctioned SaaS-SSO, security configurations, and vendor approvals. 

IT and security managers who fail to appreciate the inherent risk of this shadow world can no longer maintain an accurate sense of their security posture. The numbers are telling. According to Okta, a SSO provider, only 88 apps use SSO in the average enterprise. Imagine what that means when average industry use often surpasses hundreds of applications per enterprise. 

We must be better prepared, and the very first step in building a viable SaaS threat model is to establish and analyze organizational SaaS inventory. The more granular, the better. At the very least, they should communicate which apps are operating in an organization’s environment and which individuals are using them. To fill in this knowledge gap quickly and without doing so at the expense of other critical operations, we must introduce more automation to SaaS security. 

Shadow Applications and their Risks

Shadow SaaS apps are not dangerous because they are unknown. In fact, users tend to work with viable solutions that, in most cases, would have received approval. Rather, real SaaS risk lies in the combination of SaaS app internet accessibility and its separation from IT workflows.

Unlike SSO-connected or self-hosted apps, access to the information stored on SaaS apps is solely controlled by users—the weakest link in our security chain. Access to shadow apps cannot be revoked by IT and security teams due to a lack of awareness over app use or the technical means to revoke access. This creates dangling access to critical information as users change their roles or leave the organization. 

Mindful security leaders must consider how they can leverage SaaS security innovation to unify offboarding for all discovered SaaS, as well as accelerate internal risk assessments and SSO integrations. Remember, users are susceptible to password phishing attacks, which can be significantly reduced by SSO and MFA integrations. However, achieving a security baseline with these integrations is hardly trivial. When discovering new application use within the organization, IT teams are required to detect the administrator of the application itself. Traditional discovery tools, such as network proxies or financial record analyzers fail to accomplish this and increase the friction required to secure the app. In many cases, the app itself does not support SSO or requires additional payment for an enterprise license, known as the SSO Tax. 

Getting a Grip on SaaS Access

For too long, access monitoring has relied on network or endpoint-centric solutions despite malicious access to SaaS, both internal and external, rarely ever originating from the office itself. Without visibility into asset access patterns, enterprises have been left with a legacy of missed sensitive connections and meaningful insight into their security postures. Moreover, though traditional data loss prevention DLP requires a closed perimeter in which data moves freely—limiting exfiltration of data from the perimeter—SaaS usage requires breaching this perimeter by design. Understanding that SaaS users always upload data to an internet-based third-party vendor, security leaders understand that the definition of DLP for SaaS must change. Today, the definition must focus on data movement in the SaaS app itself, as well as user devices.

The predominance of WFH and BYOD requires that these measures include a risk-based approach to secure user access based on location, device and identity. Moreover, vendor approval processes are an integral part of a good security posture. Nevertheless, once an app is approved, additional security measures must follow to ensure continued safe use. High-risk applications access, for example, should be limited to corporate devices with active EDR solutions. Access from personal devices, even after approval, must still be logged and monitored. 

SaaS access managers must enforce coherent access policies for every SaaS connected to their organization’s environment and continuously track and limit data movement. Even beginning with read-only SaaS access - viewing without downloading files or expiration dates for downloaded information is a massive step in the right direction.

According to a survey by PTC, 59% of experts polled see security as the critical barrier to selecting SaaS solutions. This decision-making should not be so complex, and, clearly, IT and security leaders have a lot to do to survive the future’s SaaS-dominated landscape. Luckily, the market has taken notice, and IT and security leaders hardly have to go it alone anymore. With automation and a growing selection of new SaaS-centric governance technologies, these leaders can finally adapt to persistent WFH and BYOD trends by governing access to get the grip they need on SaaS security.