Why VPNs can complement SASE | #linux | #linuxsecurity

Credit: Dreamstime

The pandemic has accelerated the development of better ways to serve and secure remote workers, which make it a good time to reexamine VPNS.

Recently VPNs have received technical boosts with the addition of protocol options that improve functionality far ahead of where they were when first invented. At the same time, new security architectures zero-trust network access (ZTNA), secure access service edge (SASE), and security service edge (SSE) are making inroads into what had been the domain of remote-access VPNs.


ZTNA’s main thesis is that users need to authenticate every user and device that wants network access. Instead of granting wide swaths of privileged access, they are stingy about what they grant when and to whom. This is because zero-trust assumes that threats can originate both inside and outside the corporate network. 

While some enterprises have forsaken IPsec VPNs entirely for more comprehensive ZTNA-based networks, they still need other kinds of protection, such as encrypting employees’ smartphones from being tracked and hacked when they travel.

Cloudflare has a nice explanation of the differences between ZTNA and VPNs, focusing on three features:

OSl layers: IPsec VPNs operate at layer 3, the network layer, while ZTNA—and by extension SSE and SASE—operates mainly at layers 4 through 7 via gateways and using web protocols such as TLS. 

This means ZTNA offers more complete protection, especially when it comes to protecting specific apps and devices. But layer 3 protection is useful to block broader malware movements and to segment the network for particular classes of users.

On-premises hardware and software: Most corporate VPNs require their own on-premises servers that endpoints connect to via client software on each endpoint device. That means the server can be a single point of failure, and usually means traffic to and from cloud-based resources must pass through the corporate data centre that houses the server, adding latency. 

ZNTA has a lighter footprint and is typically implemented with cloud-based resources and can operate with or without specific endpoint software agents. When they do employ agents, they can add to the endpoint’s CPU load.

Granular control: Most VPNs are geared towards securing an entire network by providing a protected tunnel through which remote machines can gain access to the network. That sounds good in theory but is bad in practice because a single infected endpoint that gains access can serve as the jumping-off point for a malware attack on the entire network. 

ZTNA can be more precise by restricting both network access and application access and can therefore enforce fine-grained policies that allow access for a specific user on a specific device at a specific time for a specific application. This adaptive and more flexible security is a big benefit when dealing with unmanaged, BYOD-type devices, or IoT devices that don’t have any client software to secure them. 

ZTNA can also be used as a way to unify various security management tools. For example, Palo Alto Networks’ Prisma Access uses ZTNA to combine its firewalls, cloud access security brokers and SD-WAN tools.

Despite these differences, there are situations where VPNs and ZTNA can co-exist. For example, a VPN can be used when connecting a remote office or when users need to connect to on-premises file servers. VPNs warrant a closer look right now for two reasons. First, VPNs and ZTNA can complement each other and provide a more comprehensive security envelope, especially as large numbers of workers remain in remote locations.

But more importantly, the VPN protocol environment has greatly improved over the past 15 or 20 years. IPsec has been largely replaced by version 2 of Internet Key Exchange (IKEv2), a tunnelling protocol that is supported by Windows, macOS, and iOS. 

It also includes network address transversal (NAT) that provides faster tunnel reconnections for mobile devices as they move, uses AES and Blowfish for better encryption, and certificate-based authentication to prevent man-in-the-middle attacks. IKEv2 is also supported by many enterprise VPNs such as Cisco’s SSL AnyConnect and Juniper’s VPN products.

Original Source link

Leave a Reply

Your email address will not be published.

sixty five + = 67