Many midsized and large-sized enterprises utilize technology solutions like single sign-on (SSO), endpoint detection and response (EDR), and mobile device management (MDM) as part of their overall systems management solution. However, these solutions don’t always work well for employees who need to remotely access their corporate network over a virtual private network (VPN). What are some difficulties or limitations when SSO, EDR, and MDM are used over a VPN connection? I recently asked Tarun Desikan, COO and co-founder of Banyan Security about this. Here are his responses to my series of questions.
MITCH: Tarun, let’s examine this matter piece by piece, starting with SSO. What are some difficulties or limitations involved when SSO is used over a VPN connection?
Tarun: Today, most enterprises have migrated SSO away from traditional on-premises Active Directory to cloud IDPs such as Azure AD, Okta, and OneLogin. These cloud IDPs then serve as the employees’ portal to authenticate into other multi-tenant cloud services such as Microsoft Office 365, Google Workspace (aka G Suite), Salesforce, and AWS.
Forcing a VPN to authenticate to a cloud IDP (which, by definition, is made available on the Internet) has many limitations. First, you degrade your employees’ user experience. Instead of simply clicking on a button to access their cloud resources over the Internet, they now need to fire up a VPN and backhaul traffic to the corporate network to get access. It can be painfully slow, and workers on the go or on mobile devices particularly hate this process.
Second, you don’t actually improve security. We have heard of innumerable cases where employees turn on the VPN just to authenticate with the Cloud IDP and then immediately turn off the VPN for the rest of the day, so they have high-performance internet access to their applications. The security team checks a compliance box, and the users do what’s needed, but this kind of system actually hampers overall enterprise security.
Finally, the VPN approach requires IP whitelisting-based systems that are complex to operationalize and maintain. The simple act of adding third parties, such as contractors and vendors, to your cloud IDP now requires complex firewalling or dedicated devices. Enabling developers to run cloud workloads or provisioning programmatic access turns a simple service account creation flow into a complex network connectivity problem.
VPNs were designed for a world where SSO was implemented via an on-premises Active Directory. VPNs are now an anachronism in an era where SSO is implemented using cloud IDPs.
MITCH: Let’s look at EDR, which helps keep your network secure. Can an EDR solution work smoothly together with a VPN approach to providing remote users with corporate access? Or are there some problems that can crop up?
Tarun: VPNs are designed to enable network connectivity, not to continuously enforce security policies. So, once a user authenticates and gets onto the network, the VPN’s policy enforcement job is essentially done.
When the EDR solution (that is focused on continually monitoring and responding to endpoint threats) detects malicious activity on a user’s device, there is no way to send that signal to a VPN so it can modify its network connectivity policies.
Most EDR implementations do provide a “hammer” of completely shutting down internet access on a device, but that is typically too heavy-handed for most scenarios.
VPNs are designed to enable network connectivity, not to continuously enforce security policies. So, once a user authenticates and gets onto the network, the VPN’s policy enforcement job is essentially done.
What you really want is a way to use signals from the EDR to modify, in real-time, the access privileges assigned to a user and device. That is, if the EDR detects suspicious activity, redirect the user to a remediation portal. Or, if a user turns EDR off on a device, block access to high-risk resources but allow them to contact support for help.
You cannot create these types of policies with VPNs.
MITCH: How about integrating MDM with VPN remote access. Are there any security, usability, or manageability issues associated with this kind of setup?
Tarun: Deploying remote access capabilities via device management makes a lot of sense because IT can centrally manage both.
However, when it comes to mobile devices and deploying VPN via MDMs, IT pros need to keep a couple of their user’s concerns top of mind:
- Privacy: Many users (contractors, employees using personal devices, etc.) do not want their devices managed/controlled by an enterprise MDM
- Performance: Many users won’t tolerate the battery drain caused by VPNs on mobile
From an administrative perspective, the MDM+VPN strategy also lacks the flexibility to create different policies based on device type – unmanaged, unregistered, BYOD, etc. — and to continuously enforce those policies.
So while integrating MDM and VPN for remote access could make sense, there are many scenarios where alternative strategies would likely serve an enterprise’s mobile users better.
MITCH: I understand that Banyan has an approach to providing secure remote access that avoids these kinds of problems and integrates well with SSO, EDR, and MDM solutions. Please explain how this works from a technical standpoint since most of our readers are IT pros.
Tarun: The diagram below explains the technical flows to enable a modern “Zero Trust” security model.
Banyan integrates with your SSO/MFA via SAML, and your UEM/MDM and EDR via API hooks. Every time a user tries to access a resource, Banyan computes a trust score based on user and device trust, device security posture, and resource sensitivity. This Banyan TrustScore then powers a policy engine to enable continuous authorization aligning the risk of the request with the sensitivity of the resource, revoking access midsession if warranted.
Banyan has created a reliable, simple, and scalable Zero Trust Network Access (ZTNA) solution that enables fast, easy provisioning of user-to-application segmentation, giving users and developers passwordless, one-click access to complex infrastructure and applications from anywhere — without requiring network-centric solutions like VPNs. Our Trust-Based Access Control offers granular control, and our Enterprise Edge makes for the industry’s most flexible deployments.
MITCH: How does one go about implementing your solution for a typical enterprise?
Tarun: At Banyan, we have an onboarding framework that provides assurances along the way and helps obtain security posture with low user impact, ultimately helping build buy-in from employees across your organization. Getting started with Banyan and ultimately tracking your Zero Trust journey boils down to four steps:
- Identifying a Proof of Concept (PoC) application
- Understanding your devices and their respective trust levels
- Enforcing an access policy
- Securing additional services
We start by identifying a PoC application. Because Banyan can be inserted transparently without having to make network changes or disrupt your end users’ existing access workflows, you are able to immediately get visibility into the users that are accessing this PoC application.
The next step is to get a better understanding of the devices being used to access the PoC application. Banyan has multiple ways to register devices seamlessly. Zero Touch Deployment allows for a completely silent installation and registration via the Banyan app. A user can also register their device manually with just a few steps. As device registrations progress, we begin to get insights into the device platforms and their trust levels.
Now, we’re ready for the third step. The Banyan access policy for the PoC application has been running in “Learning” mode thus far, and we have now cataloged the bulk of users and devices accessing the application and know exactly which users will be impacted when the policy goes into ‘Enforcing’ mode. Knowing this impact is crucial for a successful rollout of any Zero Trust product. Once we’re confident in the impact it will have, we can now enforce our first Zero Trust policy.
With this initial implementation under their belt, organizations can now begin to protect additional hosted web, SaaS, and infrastructure access with Banyan.
MITCH: How does Banyan’s zero trust solution compare with other solutions in the marketplace? That phrase “zero trust” is bandied about a lot lately — what does it mean exactly in the context of Banyan’s own solution?
Tarun: Most zero trust solutions in the marketplace are just rebranded VPNs — the same underlying technology with a new splash of marketing. At their heart, VPNs do what they are designed to do — connect two networks. They often cause a performance hit and grant overly broad access without the requisite security controls to continuously enforce least privilege access and device trust.
Banyan has been designed from the ground up for “Zero Trust,” providing Enterprise-grade trust-based access control for all environments (cloud and datacenter), where users connect to their application with single click, security policy is continuously authorized and enforcement can be deployed in minutes via an Enterprise Edge network.
Most zero trust solutions in the marketplace are just rebranded VPNs — the same underlying technology with a new splash of marketing. At their heart, VPNs do what they are designed to do — connect two networks. They often cause a performance hit and grant overly broad access without the requisite security controls to continuously enforce least privilege access and device trust.
MITCH: Please add any last words you’d like to say on the topic.
Tarun: “Zero Trust” can be quite a polarizing term in the IT community. There is a lot of hype and unrealistic expectations. But if you peel the onion a bit, you’ll also see that the security fundamentals are strong and there is an emerging set of solutions such as Banyan that can enable a significantly better security posture for your enterprise and provide a superior user experience as well. We encourage you to explore them.
MITCH: Thanks very much for giving us your thoughts on this subject.
Tarun: You’re most welcome.
Featured image: Shutterstock
