A software-defined perimeter is the zero trust alternative to virtual private networks (VPN) for secure remote access to any application, located anywhere. The original concept of the zero trust SDP model was straightforward. You didn’t trust a device just because it belonged to an employee and was connected to the local area network (LAN). Ideally, the zero trust movement means that “nothing” is trusted.
The zero trust SDP definition was extended to include a combination of micro-segmentation along with identity-based access. Micro-segmentation provides improved isolation, segmentation, and control of the network. Identity-based access ensures that upon login, users are not authenticated once or twice, but continually verified, and their activities are checked to detect anomalies.
It is mistakenly assumed that because a device belongs to an employee and is on the LAN, it should be allowed network access, even when that device is connected remotely over a VPN. However, if we shine the torch on our past experience, we will realize that security professionals need to be very cautious about granting network access.
Location-based network design
The zero trust software-defined perimeter concept introduces an approach to networking that is different to the way networks are commonly designed today. Currently, the design of the network topology is not around users and the resources they need to access; rather it is built around branches and data centers.
The traditional way to design networks is not identity-based but is based on physical location. Compared to a zero trust network design, this eventually falls short in a number of ways, especially as the perimeter becomes less clear.
The perimeter is now fluid
In the past, life was simpler since we had statically-wired corporate-owned devices accessing static, well-defined enterprise applications. However, now we have multiple devices (corporate and personally owned) connecting from everywhere. Today, there is also a rapid migration of applications to software-as-a-service (SaaS) and infrastructure-as-a-service (IaaS) environments.
As a result, we are no longer shielded by a secure network perimeter with clear demarcation points. Mobile users, bring your own device (BYOD) and cloud applications are testing the limits of the traditional VPN architecture. Yet businesses rely heavily on VPN access for seamless productivity.
VPN security and usability issues
The first issue with VPN today is security – users that log into the VPN and gain broad network access. Even if the network is well-designed and segmented, a wide range of network resources are visible to attackers.
Let’s not forget the user experience: when you have to backhaul traffic to a centralized data center for VPN termination or for security purposes, there is latency which degrades the application’s performance. In addition, users often need to deal with unreliable client applications and complex configurations. If you have one VPN concentrator and backhaul to that one location, there may not be too much of a problem besides latency. However if, for example, you have 3 VPN concentrators and the user needs to select the correct one, they have to know where the application is located.
Cloud-scale issues
Operationally, once you have thousands of internal employees and third parties remotely accessing applications, defining policies and synchronizing them across different locations is complex. In addition, deploying, configuring and managing VPNs in tens or hundreds of cloud instance is expensive, time-consuming and risk-prone.
The misuse of VLANs
Initially, network design was based on zones. The original use case of VLANs focused on improving performance by dividing broadcast domains. However, over time their role evolved to providing security for which they were never really intended.
They are not the optimal technology to span across multiple locations. Take into consideration the cloud where VLANs are not supported in their native form. How do you bridge from AWS to Google clouds and carry VLANs across them? How do you perform management and synchronization when each cloud provider or data center has specific segmentation scheme?
The right way forward – micro-segmentation
Micro-segmentation represents the first stage to zero trusts. There is a compelling need to create a logical network where users only see what they are entitled to. Micro-segmentation takes the traditional zone-based architecture and further segments networks within the zone into a single application or service.
Micro-segmentation is a step in the right direction; however, it does come with certain issues. Firstly, it uses binary rules with a simple allow or deny. This is an all or nothing approach, also it does not allow for more intelligent, dynamic and granular rules. Another challenge is that by default, it does not take into consideration identity, location or device posture.
You need to synchronize all the IP addresses and identities across networks, data centers, and clouds. Rules governing what users and devices can do based on IP address and the TCP/UDP ports cause headaches for consistent Role Access Control (RBAC) while users roam between different networks.
We all know that IP addresses change across the subnet boundaries and across time. As a result, we need to keep all the DHCP logs and make a coherent stream of data that can be fed to an external system such as security information and event management (SIEM) as well as to the security appliances across your networks. This ultimately requires a lot of detective work.
Despite such grinding efforts, you still have to work hard to partition all your networks. You need to partition across all the data center and cloud locations and then base it on the identity of the user. You need to make sure the network is partitioned so that the identity can access the right services, which can be hard to manage and scale efficiently.
Micro-segmentation must be based on identity
The point is that your objective is to identify users in a way that is permanent, regardless of their point of connection. This enables IT administrators to quickly understand what is happening in the network without indulging time-consuming detective work. In addition, it allows you to consistently put the access policy rules in place across the network.
Instead of identity being an afterthought, we need an identity-based solution that can act and make decisions based on the information we have, such as device type, location, and ownership.
The second issue is with authentication. IP addresses are not designed to be an authentication mechanism. The solution must make sure that the traffic carries the identity.
What’s next for the zero trust network design?
The challenge for today’s enterprise is to consolidate both network and security delivery for mobile users. To convert the traditional VPN remote access into a low-risk, a coherent solution is a big challenge.
A uniform solution like a zero trust software-defined perimeter is required to provide access to data and applications that are not tied to a physical location. Managing the access and setting policies should be done centrally. What’s needed is a globally distributed abstraction layer that sits on top of the existing infrastructure, thereby providing seamless access from anyone to anywhere and site-to-site connectivity. Identity and micro-segmentation should be built-in.
To learn more about Zero Trust SPD vs VPN and to understand why now is the time to make the switch, check out our recent white paper.
Learn more about Proofpoint’s approach to Zero Trust.
Subscribe to the Proofpoint Blog