Co-author: Den Jones
Do your employees complain about needing to use their corporate VPNs to access SaaS applications such as Microsoft Office 365, Google Workspace and Salesforce? Does your enterprise security model require backhauling traffic destined for SaaS applications through corporate VPN gateways or concentrators? Is your IT operations team constantly configuring and updating IP Whitelists across the numerous SaaS vendors your organization uses? If so, this post is for you. We’ll share why you need to move beyond traditional VPN-based techniques to secure today’s distributed workforce and their SaaS applications. We’ll propose a simpler technique – device posture checking with continuous authorization – that improves the user experience, enhances security and reduces operational complexity.
A Brief History Lesson
Let’s talk a bit about corporate VPNs and why we needed them all those years ago.
Hark the Internet
In the late 1990s, companies started getting on the internet and began enabling remote employee access to internal systems. Initially, I recall this being limited to technology administrators to provide support; however, as the years rolled on, that quickly expanded to other roles.
By the early 2000s, regular employees began to use corporate VPNs to access internal services like email, HR, ERP, and other core systems. The wave of usage started with techies who had computers at their house or were early laptop users – but of course, with internet access in their homes. As the early 2000s progressed, using corporate VPNs to access internal resources became a basic expectation.
Back then, and for many years until the cloud emerged, the only applications you would access were inside your network. VPNs were the way to go. More network security functionality – IDS / IPS / DLP / SWG – became bundled in with corporate VPN stacks. VPNs also acquired features like auto-start and pre-logon that made it easy for remote users to always be connected to the corporate network.
Enter the Cloud
By 2010, the move to cloud environments was in full swing. Salesforce, Dropbox, Workday … more and more internal services began to move from on-premises to the cloud.
However, IT teams were still fairly suspicious about these cloud applications; they wanted to control access to them as if they were still hosted on-premises. So, even though you could connect to these SaaS applications directly over the internet, many organizations configured IP whitelists so you could only access them from corporate IP address ranges. This worked fine because most users were in the office anyhow; remote users just needed to log on to the corporate VPN to access these SaaS applications.
The Post Pandemic World
Fast forward to today. Most organizations are cloud-first – they prefer to subscribe to a SaaS application over hosting it themselves. Post the COVID pandemic, our workforces are increasingly remote – they may or may not be in the office. Yet, we still rely on that beloved VPN and IP whitelisting and a security model that was designed for a world from 20 years ago. No wonder employees are complaining and we have operations and security challenges.
VPN != Security
Using a corporate VPN for access to SaaS applications is often equated with a robust enterprise security model; so let’s break that down.
VPN Security Model
There are 4 core security features that a corporate VPN gives you:
- Encryption – traffic between your local device and the VPN gateway cannot be decrypted or manipulated by man-in-the-middle attacks
- Packet inspection – once traffic gets to the VPN gateway it can be inspected for malicious content and/or sensitive data
- Block untrusted devices – only users and devices on the corporate network can access the SaaS application
- Device posture – only trusted devices with an approved device posture can connect to the corporate network
In the early days of the internet, these were very useful features; however they are not all relevant today for access to SaaS applications.
Let’s start with encryption. We are in the era of HTTPS everywhere and the free Let’s Encrypt certificate authority. Every SaaS vendor uses TLS so you’re guaranteed end-to-end encryption from browser/app to SaaS application. The corporate VPN layer is an additional layer of encryption that doesn’t do anything significant anymore.
Then, let’s look at packet inspection. By definition, SaaS vendors are cloud services that you trust with your organization’s data. Inspecting the packets flowing to these SaaS applications is superfluous and unnecessary. Further, many SaaS vendors (Microsoft, Google, etc.) use advanced protocols and techniques such as TLS 1.3 and certificate pinning that prevent any sort of packet inspection. In fact, Microsoft recommends against adopting a proxy-CASB solution; see here for more details.
Finally, corporate VPNs are used to block untrusted devices and ensure device posture before accessing corporate SaaS applications. These are valid security requirements and, once you peel back the onion, this is what the corporate VPN technique essentially provides.
Mandating VPN use to access SaaS applications has several associated drawbacks:
The reality is that the VPN user experience remains clunky and another source of frustration. Especially during login, “Really? Another username, password, and MFA challenge?” Further, once you require a VPN to access SaaS applications, you disrupt common mobile workflows.
“Oh I really want to install the corporate VPN client on my personal mobile device so IT can view all my mobile traffic.” – Said no employee, ever.
When you force all traffic through your VPN, you have to keep up to date whenever there are changes to these services. Most notably with Microsoft 365 is the headache of whitelisting/allowlisting – here’s the ever-changing list. Complex access controls based on IP addresses make it harder to know who’s got access to what – over the years this bloats and is rarely cleaned up.
Worst of all, VPN-based security has multiple unintended security consequences. Pre-logon VPNs designed to reduce user friction can be easily hacked. Full-time employees on a VPN are typically granted complete access to the corporate network – when the employee gets compromised, the attacker has unfettered access. Also, consider that contractors and third-parties often need to be given network access, further increasing the risk.
A Better Way to Secure Access
Fortunately, there is a better way to achieve the real security benefit of using a VPN to access SaaS applications – device posture and blocking untrusted devices – without all the hassle of backhauling traffic and maintaining IP whitelists. In some circles, this is called “zero trust” security.
The key idea is to uniquely identify all devices by deploying device certificates to all approved devices. These device certificates should be tied to the user and the specific device, stored in a secure location (e.g., TPM) with controls to prevent and detect tampering. Now, we have strong, unique, and immutable device identities that enable mutual authentication and secure connections.
When configured appropriately, these device certificates can also be used for first factor authentication, instead of username and password, providing a “passwordless” user experience.
Integrate Device Trust Into SSO Authentication
With device certificates deployed, you can now insert device trust and posture checks into the Single Sign-On (SSO) authentication workflow.
Typically, we allow a user to access their SaaS applications via SSO user authentication. So, we know it is “John Doe” who has signed in, but, without knowing anything about the device or its posture we have no idea really who’s actually getting in.
By integrating device trust into the authentication flow, we can now look at the user and device identity, the device posture, and create a quantifiable trust or risk score that’s evaluated via policy to determine whether to allow access. By creating policies we can determine if we want to passively know the status of our fleet of devices or actively block the access.
The final piece of this approach is to employ continuous authorization, so any change to user or device posture is reflected in the access control decision. One common approach is to integrate Device Posture with an Endpoint Detection and Response (EDR) tool. If any indicator of compromise (IoC) is detected, you can revoke access immediately. Another approach is to leverage a Security Information and Event Management (SIEM) system to detect anomalous events, and feed that back into access decisions.
Using device trust integrated with the SSO authentication flow has numerous benefits when compared to the traditional VPN-based approach.
You users enjoy a significantly superior experience not needing to turn on a VPN to access their SaaS applications. When you leverage the device certificate during authentication, you can also configure “passwordless” access – eliminating another cause of friction for users. Finally, you can enable great mobile support, supporting users who are on the road and need to access applications from a broader range of devices.
Another advantage of this approach is its simplicity – you assert device posture in the authentication flow. This gives your IT teams the opportunity to simplify architecture, operations and processes. It can cost significantly less as well – backhauling traffic through a VPN doesn’t just introduce latency, it also can incur huge bandwidth costs. Finally, device trust integrated with the SSO authentication flow can be rolled out incrementally to specific groups of users and applications instead of requiring big-bang wholesale changes. Last, it’s worth pointing out that this approach is inherently simple, reducing rather than increasing network complexity.
The zero trust approach also provides many security benefits. Certificates offer a higher level of security, as compared to passwords that are often reused across multiple applications. When a single device is compromised, its certificate can be revoked, whereas a password and account having to be disabled or changed can be very disruptive. This technique also enables granular security policies – you can determine what risk level is acceptable to access your applications and data, and configure policies so that different roles, locations, OSes or installed endpoint applications change how access is provisioned.
In this post we dove into why organizations still use corporate VPNs and IP whitelists to secure today’s distributed workforce and their SaaS applications. We detailed a simpler technique – device posture checking with continuous authorization – that enables you to control your risks while improving user experience.
The post Article 1/5: Stop Using VPNs and IP Whitelists to Secure Access to SaaS Applications first appeared on Banyan Security.
*** This is a Security Bloggers Network syndicated blog from Banyan Security authored by Tarun Desikan. Read the original post at: https://www.banyansecurity.io/blog/article-1-5-stop-using-vpns-and-ip-whitelists-to-secure-access-to-saas-applications/