What is a Software-Defined Perimeter (SDP)?

What is a software-defined perimeter?

A software-defined perimeter, or SDP, is a security technique that controls access to resources based on identity and forms a virtual boundary around networked resources. By establishing a perimeter via software versus hardware, an SDP can hide an organization’s infrastructure — regardless of where it is located — from outsiders. SDP architectures can help reduce the attack surface and mitigate internal and external network security attacks.

The framework is based on the U.S. Department of Defense’s Defense Information Systems Agency’s (DISA) need-to-know model from 2007, in which all endpoints attempting to access a given infrastructure must be authenticated and authorized prior to entrance. In 2014, the Cloud Security Alliance (CSA) released its SDP working group guidance, which incorporated elements of DISA’s work with security standards from the National Institute of Standards and Technology (NIST) and other organizations. The CSA released version 2.0 of its SDP framework in 2022, which addressed component onboarding and using SDP for nonhuman entities, as well as expanded on SDP’s role in zero trust.

SDP use cases

One of the main benefits of an SDP is that it lowers the chances of successful network threats, including denial-of-service (DoS) attacks, man-in-the-middle (MitM) attacks, brute-force attacks, port scanning, server vulnerabilities and lateral movement attacks, such as Structured Query Language (SQL) injection or cross-site scripting (XSS).

SDP use cases also include the following:

• SDPs support a variety of devices. The virtual perimeter can authenticate laptops and personal computers, as well as mobile and internet of things (IoT) devices. SDPs ensure connections can’t be initiated from unauthorized or invalid devices.
• SDPs restrict broad network access. Individual entities aren’t granted broad access to network segments or subnets, so devices can only access the specific services and hosts permitted by policy. This minimizes the network attack surface and prohibits port and vulnerability scanning by malicious users or malicious software.
• SDPs support a broader risk-based policy. SDP systems make access decisions based on numerous risk criteria, including threat intelligence, malware outbreaks and new software.
• SDPs can be used to connect anything. SDP technology enables connectivity to only the IT resources needed by employees without cumbersome management requirements or mounting hardware costs.
• SDPs enable control of services, applications and access. SDPs can control which applications and devices can access specified services. This limits the attack surface and stops malicious users or malware from connecting to resources.
• SDPs are instrumental to application isolation. An SDP deployed within an enterprise data center isolates mission-critical application infrastructure and data from unauthorized users. Hackers are unable to find or infiltrate these applications because they are cloaked by the SDP.
• SDPs help secure hybrid and private clouds. SDPs enable enterprises to hide not only public SaaS, IaaS and PaaS cloud instances, but also hybrid cloud environments that use both public and private cloud.

SDP architecture

SDP technology creates a secure perimeter based on policies used to isolate services from unsecured networks. These policies use the access control principle of least privilege to secure devices, giving users and devices only the access they require to perform the task at hand.

An SDP framework provides an on-demand, dynamically provisioned, air-gapped network — a segmentation of network resources that mirrors a physically defined network perimeter but operates in software rather than via an appliance — by authenticating users and devices before authorizing the user/device combination to securely connect to the isolated services. Unauthorized users and devices cannot connect to the protected resources.

When authentication is completed, trusted devices are given a unique and temporary connection to the network infrastructure. The SDP framework enables companies to streamline operations when it comes to user authentication and application security.

SDP architectures are made up of two main components: SDP controllers and SDP hosts. An SDP controller determines which SDP hosts can communicate with each other. An SDP host can be either initiating or accepting. An initiating SDP host communicates with an SDP controller to determine which hosts they can connect to. An accepting SDP host only accepts allowed communications and connections from an SDP controller. Some SDP architectures use gateways that act as the accepting host between the two connecting devices/users.

The SDP architecture consists of two components: SDP hosts and SDP controllers.

Encrypted connections — often virtual private network (VPN) tunnels — between controllers, hosts and gateways keep all communications and users/devices secure.

SDP deployment models and workflows

SDP deployment models can be characterized by the way they structure interactions among clients, servers and gateways. The primary SDP approaches include the following:

Client-to-gateway deployments position servers behind an accepting host, which acts as a gateway between the protected servers and the initiating hosts. The client-to-gateway SDP can be deployed inside a network to reduce lateral movement attacks, such as operating system (OS) and application vulnerability exploits, MitM attacks and server scanning. It can also be deployed directly on the internet in order to segregate protected servers from unauthorized users and mitigate attacks. This model is well suited for organizations using cloud-based applications, as well as those that want to secure on-premises legacy applications.

Workflow of the SDP architecture.

Client-to-server deployments are similar to client-to-gateway deployments except that the server being protected by the SDP is the system that runs the accepting host software instead of the gateway. Deciding between the client-to-gateway and the client-to-server deployment is usually based on a number of factors, including analysis of load-balancing needs, the servers’ elasticity — how adaptable the cloud server is to changes in workloads — and the number of servers an enterprise needs to protect behind the SDP. This model is useful for organizations with cloud-based applications.

Server-to-server deployments protect servers that offer representational state transfer (REST) services, Simple Object Access Protocol (SOAP) services, a remote procedure call (RPC) or any kind of application programming interface (API) over the internet from all unauthorized hosts on the network. With this model, the accepting host would be the server with REST, SOAP, RPC or API. This model is applicable to organizations with cloud-based IoT and/or virtual machine (VM) environments.

In the client-to-gateway SDP model, one or more servers are protected behind the gateway.

Client-to-server-to-client deployments depend on a peer-to-peer (P2P) relationship between the clients. In this deployment, the SDP obfuscates the IP addresses of the connecting clients, with the server acting as the intermediary for both clients. This model is well suited for organizations using applications such as chat, video conferencing and IP telephony.

Client-to-gateway-to-client deployments are variations of the client-to-server-to-client model. This model also supports P2P, with each client acting as an initiating host, accepting host or both when connecting with each other.

The client-to-gateway-to-client SDP model is used to secure client-to-client communications.

Gateway-to-gateway deployments involve one or more servers sitting behind an accepting host, with the accepting host thereby acting as the gateway. Additionally, one or more clients sit behind an initiating host, using the initiating host as a gateway. This model is curated for networked and IoT devices on which SDP clients cannot be installed, such as printers, scanners and smart sensors.

SDP vs. VPN: What are the differences?

The most common benefit of a VPN is its ability to provide users and third parties remote access to isolated networks. Yet the following two security risks make VPNs an inappropriate method for providing remote access to isolated networks and applications:

• Credential theft. This risk is doubly impactful to VPNs because people tend to use the same username and password across numerous websites. Because it is possible the credentials people use to access their social media accounts are the same as their remote access VPN accounts, credential theft is the most common and most effective network attack vector.
• Excessive access. A VPN provides a user a slice of the network with wide and often excessive access to network resources, including the infrastructure Dynamic Host Configuration Protocol (DHCP), DNS, switches and routers. Not only does this provide a large attack surface for a bad actor, but it also gives legitimate users access to far more than the one or two applications they really need.

Administrators should complement their VPN infrastructure with SDP tools. Together, they can navigate security challenges, including those in hybrid and multi-cloud deployments, reducing potential attack surfaces and protecting key data. With SDP software, network administrators can dynamically deploy highly available microperimeters for hybrid and multi-cloud environments to isolate services for fine-grained user access.

A compromised device is the biggest challenge of using a mobile phone or tablet as a VPN access device. Any device that accesses an isolated network via a VPN presents the risk of bringing malware to that environment. Nothing in the VPN connection process assesses the state of a device. If any type of malware is on an access device, the malicious software could propagate across the VPN into the broader isolated network — creating untold havoc, for example, in ransomware situations. With an SDP, end devices are inherently considered untrustworthy.

How SDP and zero trust relate

While some experts use the terms SDP and zero trust interchangeably, the two have differences.

SDP is a way to implement zero trust at the network level. It is an effective architecture for adopting the zero-trust security model, with zero trust often labeled as the philosophy behind the SDP architecture. SDP controllers know the zero-trust policies for authentication and authorization, while SDP gateways and accepting hosts enforce them.

The zero-trust network security model assumes all users, devices and transactions may be compromised, regardless of location. Therefore, the model’s basis is to trust no one. Like an SDP, the zero-trust model functions on the basis that traditional perimeter-based security is ineffective.

Zero trust is a wider concept of which SDP is a part. Zero trust often includes other elements not required in an SDP deployment. The basic concepts of SDP and zero trust, however, follow the same basic tenet that a person’s or device’s identity must be verified, regardless of where it is.

Deploying SDP and zero trust in tandem will ensure the network and its resources are cloaked via SDP, while authentication measures are followed via zero trust.