What is a Software-Defined Perimeter (SDP)?

As a concept, the Software-Defined Perimeter (SDP) promises to solve the growing information security challenges IT departments face. But in an industry awash in buzzwords, how do you separate reality from hype? The first step is to understand what an SDP actually is and how it makes networks more secure than traditional VPN systems.

What is an SDP?

The castle-and-moat framework companies once used to secure their networks is too brittle to handle the more nebulous security perimeters of today. Proprietary resources once confined to an on-premises network are now hosted on the cloud. And many proprietary resources have been replaced by X-as-a-Service providers.

The evolution of the business workforce further compounds the security problem. Bring-your-own-device policies create new vectors through which the perimeter can be breached. And a constantly-shifting population of contractors and third-party partners makes access management even more difficult.

The software-defined perimeter offers a more flexible framework by removing trust from the equation entirely. Rather than defending a network freely accessible to trusted users, SDP defends each resource — proprietary or cloud-hosted or X-as-a-Service — with zero-trust access policies.

Whether an incoming connection to a resource comes from the CEO’s managed device or another resource on the proprietary network, the connection request is treated as if it came from a computer in a random internet café.

How Does an SDP Work?

A software-defined perimeter consists of three elements: the SDP Controller, the SDP Access Node, and the SDP Client. These elements implement need-to-know and trust-nothing policies that prevent unauthorized access to all resources.

The SDP Controller works with identity resources like Okta to authenticate incoming connection requests. Access policies are determined on a per-device, per-user, per-session basis for each resource. Connections are only authorized when the user and device meet all access control requirements.

An SDP Access Node sits between each resource and a company’s privileged network or the public internet. The resource cannot broadcast its presence and the SDP Access Node rejects all connection requests that do not come from the SDP Controller. With the authorization, the SDP Access Node and the SDP Client create a secure, encrypted tunnel through which all data passes.

The SDP Client itself has no knowledge that any particular resources exist or where on a network the resource has been deployed. The secure tunnel with the SDP Access Node is an ephemeral connection that only lasts for the duration of the session. The authentication, network routing information, and everything else about the connection disappear. Even if the SDP Client tries to reconnect seconds later, the SDP Controller treats it as a new request.

Why Are Enterprises Moving to SDPs?

Software-defined perimeters make network management and information security simpler, more efficient, and more scalable than the castle-and-moat framework.

For example, traditional VPN systems create a performance bottleneck because the VPN gateway handles both access control and data transfer. Regardless of the physical proximity of the remote user to the resource, all data flowing between the two get backhauled through the gateway. Very little data passes between the SDP Client and the SDP Controller in the brief period they interact. And the connection between the SDP Client and the SDP Access Point can follow the most efficient route.

SDP also enhances security by doing away with the entire concept of a secure perimeter. Since a VPN gateway only facilitates access for people outside the perimeter, it does nothing to secure devices inside the perimeter. A simple USB key with a malicious payload could bypass the secure perimeter and gain access to everything on the network. In that scenario, an SDP leaves the malware with nowhere to go. All resources are hidden from the network by the SDP Access Nodes. And without authorization from an SDP Controller, any attempt the malware makes to connect to a resource gets rejected out of hand.

Moving to an SDP security framework creates other benefits for enterprises. Security policies and infrastructure can become more uniform across the organization. It becomes easier to implement fine-grained access control policies on a per-user, per-device, per-resource basis. In addition, the security of hosted, cloud-based, and X-as-a-Service resources can be consolidated within a single architecture.

While SDP has broad appeal to enterprises, the migration away from the castle-and-moat framework is a major business transformation process. However, there is a way for organizations within the enterprise, such as DevOps teams, to get the security benefits of SDP now.

Twingate’s Frictionless SDP Enhances DevOps Security

A ground-up incarnation of the software-defined perimeter framework, Twingate was specifically designed to make deploying SDP security frictionless for users and administrators alike. As with the general framework, Twingate consists of Clients, Controllers, and Access Nodes

The Twingate Controller integrates with your existing security stack and provides granular access controls for users and devices. One-click on-boarding and off-boarding make managing dynamic project teams much easier.

You can install the Twingate Access Node in front of your resource with a single command. Since the Access Node can handle any TCP or UDP traffic, no modifications to the resource are needed.

Furthermore, end-users and their devices cannot see the resource on your network. Only with authorization from the Controller will the Access Node create an ephemeral tunnel with end-to-end encryption to the Client.

Provisioning the Twingate Client requires no work by administrators. The end-user follows a consumer-like journey to download and install the Client on their device without any modifications needed to the device’s operating system or software load. Once installed, the always-on Client only gets access to a resource with session-by-session approval from the Controller.

Within the context of a DevOps team, Twingate’s SDP solution is a much more flexible and efficient approach to network security than the traditional VPN. Changes to permissions when employees and contractors join and leave projects can happen with a single click. Deployment of SDP requires no changes to your network infrastructure, your existing security stack, or your resources. And globally-distributed DevOps teams can work more efficiently without having to suffer the hit on network performance imposed by VPN-based security.

Contact us to learn more about how Twingate’s software-defined perimeter can improve the security of your developer operations.