No one adopts SaaS applications with the intent of them being a slower and less productive user experience versus their previous on-premises instantiations. Yet, in the age of cloud based SaaS applications and mobility (aka Work From Anywhere) performance impacting Source IP Based Conditional Access controls is somehow still a thing thats popping up in otherwise modern enterprise network and security architecture
A common example of this that I have often seen is an enterprise requiring that end user access to Office 365 be limited to only users who are coming from a known corporate source IP address. This has several unfortunate side effects, the largest being the unnecessary performance impacting latency introduced in forcing both on and off-network end user traffic back through the corporate data center further straining any centralized outbound security hardware appliances in the process. Another side effect is a poor end user experience in making them jump through hoops such as having to turn on a remote access VPN just to get access to a public cloud hosted SaaS application.
When we have open discussions with enterprises and start to break down why this is still a thing we often land on a common set of requirements that center around reduction of risk:
1.) User identity alone isn’t good enough, we need to know that the user is coming from one of our managed devices with our AV/EDR installed
2.) We want to ensure that the user is passing through our outbound security controls and that we have visibility into this key SaaS application traffic so we force them to come back on-premises
3.) We want to prevent intentional or accidental data loss
While these are absolutely important risk factors that we need to account for in our SaaS adoption strategy, we really need to rethink the mechanisms by which we employ our controls so as not to defeat the original goals of migrating to SaaS applications that no longer live on our network in the first place.
Let’s look at some of the more modern alternative methods of implementing SaaS access risk reduction while not adversely impacting performance and end user experience.
Access from managed vs unmanaged devices
Ideally this can be controlled by leveraging a combination of your SAML identity provider’s conditional access criteria and an inline cloud security solution to assess the posture of the device that the end user is requesting SaaS access from. Alternatively, we may want to grant ‘reduced’ access in the event that the end user is not coming from a managed device such that they can still reach the SaaS application, yet don’t get risky full unfettered access.
Inline Security and Visibility
For WFA scenarios this doesn’t have to mean bringing the user back onto the corporate network in order to securely access SaaS. The reality here is that we really should be assessing a combination of the current device posture and real time end user risk profile based on recently observed potentially risky behavior. Another potential attribute is where the user is coming from, not based solely on their source IP address, but through the lens of detecting ‘impossible travel’ where the user access request is coming from a completely different geo than where the user’s most recent internet/SaaS bound traffic is coming from.
Preventing Data Loss
There are multiple different potential avenues when it comes to preventing data loss from a SaaS application. An inline DLP solution (preferably cloud based) combined with an API based cloud security access broker and endpoint DLP would all help to curtail the risk of data loss without forcing SaaS access back through a centralized set of on-network security controls.
These of course work fine for our managed endpoints, but what about unmanaged? A combination of Identity Proxy and cloud browser isolation can be a powerful tandem. With an Identity Proxy in place an end user coming from an unmanaged device can be redirected by your SAML IDP to an inline cloud security solution which can now redirect this unmanaged user SaaS access request into an isolated cloud browser. This isolated browser allows the user to still get access to the SaaS application, but their potentially ‘dirty’ unmanaged device doesn’t interact directly with it. From a data protection perspective read-only access controls can be enforced to prevent file uploads/downloads and inputting of any data into the SaaS application.
Stepping Back On the Gas for SaaS
In summary there are far more thorough and effective methods of injecting risk reducing controls for SaaS access into your enterprise network and security architecture.
So let’s put the Michelin Pilot Sport tires back on our new Ferrari and migrate away from those legacy fixed location based controls. This will empower our users to be more productive wherever and whenever with out sacrificing the security and visibility of our key SaaS applications.
Disclaimer: The views expressed here are my own and do not necessarily reflect the views of my employer Zscaler, Inc.