Software Defined Perimeter: Definition, Deployment Models, Pros and Cons

Protecting the network perimeter is a cornerstone of enterprise cybersecurity. To do that, a system administrator usually configures a demilitarized zone and border routers and deploys a firewall, VPN, intrusion detection system, and other traditional security software.

This classic approach is still reliable, but it doesn’t offer complete protection. One of the key issues is the network perimeter itself. In a large organization, this perimeter includes on-premise and cloud-based solutions, SaaS, IaaS, or PaaS solutions, local and remote connections, mobile and IoT devices, and so on. That’s why a defined perimeter in a traditional cybersecurity system often looks like a complicated Dungeons and Dragons map. When all the security software is configured to protect this perimeter, scaling or changing the system is a nightmare. 

A software defined perimeter (SDP) addresses this challenge by changing the emphasis from protecting all network services and applications to protecting all devices. This relatively new approach is sometimes called a black cloud because it obscures a network from unauthenticated users.

In this post, you’ll learn how a software defined perimeter works and what the key deployment models and pros and cons are for this approach. This post will be useful for cybersecurity engineers looking for new ways to secure their enterprise network perimeter.

What is a software-defined perimeter (SDP)?

An SDP is a cybersecurity approach based on a need to know access control model. This approach enforces device authentication and user identity verification before providing access to applications and network services.

With a software defined perimeter, the network authenticates a device with the help of a multifactor software token. This token is created when the device connects to the network for the first time and includes the device’s personal identification number, serial number, and other unique identifiers. Users are authenticated with credentials that include not only a login and password but also geolocation, biometric, and other data.

Some believe that an SDP substitutes common cybersecurity instruments such as a VPN and firewall. A software-defined perimeter is different from a traditional VPN, however, as it offers a more dynamic and secure approach. VPNs typically provide a secure tunnel between a user’s device and the corporate network, granting access to all resources within that network.

While VPNs can still be useful in certain scenarios, an SDP offers a more secure and adaptable solution for modern network security needs. You can use an SDP and VPN together to enhance your organization’s cybersecurity and adapt to the demands of modern remote work environments. In our experience, the path to success lies in combining time-tested and new approaches. For example, during a recent SDP project, we used a VPN to ensure a secure connection between clients and Accepting Hosts. Now, let’s see how software defined perimeters operate.

How does an SDP work?

While there may be slight differences in various solutions, a software-defined perimeter architecture usually consists of two components:

1. An SDP Host manages connections between devices and applications. There are two types of SDP Hosts:
   • An Initiating Host communicates with an SDP controller, provides information on devices trying to connect to the network, requests a list of Accepting Hosts, and establishes a mutual Transport Layer Security (TLS) connection with those hosts.;
   • An Accepting Host connects authenticated devices to requested applications. This type of host connects only to an SDP controller and to the Initiating Hosts. 
2. An SDP controller identifies devices using an identification system (public key infrastructure, fingerprints, geolocation, OpenID, Kerberos, Active Directory, etc.). It also provides access to Accepting Hosts and enforces access policies.

By working together, all of an SDP’s components guarantee secure communication, enforce granular access control, and enhance overall network security. Various software defined perimeter vendors offer different types of solutions, but generally, an SDP workflow looks like this:

1. After receiving a multifactor token, an Initiating Host sends it and user credentials to an SDP controller. These credentials include not only a login and password but also the type of device, geolocation, biometric data (for mobile devices), etc.
2. The SDP controller passes the authentication token and credentials to an identity provider. This provider creates, maintains, and manages the information necessary for user and device identification. If identification is successful, the provider returns access rights to the SDP controller.
3. The SDP controller looks for an Accepting Host that provides access to the resource requested by the user. Then it sends the IP of that host to the initiating host.
4. The Initiating Host establishes an encrypted VPN connection to the Accepting Host.

Implementing these four steps is what allows a well-designed software defined perimeter solution to keep your critical data properly secured from various cybersecurity threats. In the next section, we explore the strengths and weaknesses of using an SDP in your operations.

Pros and cons of an SDP

Some believe that an SDP substitutes common cybersecurity instruments such as a VPN and firewall. However, in our experience, the path to success lies in combining time-tested and new approaches. For example, during a recent SDP project, we used a VPN to ensure a secure connection between clients and Accepting Hosts. 

The key benefit of an SDP is the high level of network protection. The Cloud Security Alliance has hosted three hackathons with substantial cash prizes with the goal of compromising software defined perimeter security. This cybersecurity technology has proven capable of protecting enterprise networks from the following attacks:

• Denial-of-service (DoS). In this type of attack, services are overloaded with anonymous requests. An SDP makes it impossible for an unidentified user to connect to a server.
• Brute force attack. Brute forcing multifactor authentication to gain access to a network is nearly impossible.
• Credential theft. An SDP uses not only credentials but additional data to authenticate devices and users. While it’s possible to intercept logins and passwords, stealing all the credentials required for authentication with an SDP is nearly impossible.
• Man-in-the-middle (MITM). To perform an MITM attack, a hacker hijacks communication between a user and an application. With an SDP, all communications are hidden within a dynamic encrypted channel, so a hacker can’t intercept them.
• Server exploitation. In order to exploit a server, hackers have to connect to it. With an SDP, hackers can’t connect to servers because of multifactor authentication. Connecting from outside the network is impossible because a server’s IP address and port are hidden.
• Session hijacking. Hijacking a session key is impossible because the SDP controller creates a dynamic TLS channel to transmit the key.
• Gateway compromise. It’s hard to compromise a gateway because of the complicated authentication and access procedures in an SDP. However, if a gateway is compromised, hackers can gain access only to that gateway. They can’t connect to other resources inside the network.

Besides significant cybersecurity improvements, an SDP provides these advantages:

• Zero trust policy enforcement. No device or user is trusted until it’s identified by an SDP controller. The connection between users and resources is dynamic and encrypted.
• Granular access to resources. An SDP controller connects users to a resource only if they have relevant access permissions. It’s possible to restrict access for a certain role, group of users, or a single user.
• Hiding corporate resources. An SDP can hide any information from outsiders, including the addresses of DNS servers. Identified users can connect only to those resources they have access to — all others are hidden from them.
• Scalability and flexibility. Adding a new resource (application, server, database, etc.) is easier within a software defined perimeter because you can simply add it to an existing Accepting Host. In the traditional perimeter security model, you’ll need to add the resource to all cybersecurity solutions you deploy.
• Extensibility. An SDP is built on standards-based components such as mutual TLS and VPNs. It ensures easy integration with other standard security systems.
• Support for a variety of devices (including IoT). SDP secures connections for any type of device, using a set of data (not only a password–login pair) as credentials. 
• Encrypted data transfers. All connections between hosts and controllers are encrypted with TLS, SAML, or X.509.
• Reduced network attack surface. An SDP restricts broad network access and obscures enterprise resources from hackers. It’s very hard for hackers to attack something they know nothing about.

On the other hand, an SDP has several drawbacks:

• Controller vulnerability. In an SDP architecture, controllers have a vital role, as they connect devices to protected resources. If controllers are offline, it’s impossible to establish a connection to resources.
• Network disruption during SDP deployment. An SDP differs a lot from traditional network security controls. In large enterprises, integrating an SDP solution can cause network and infrastructure disruptions because you’ll need to reconfigure all devices and applications.
• Configuration updates for applications. It will take a lot of time for system administrators to update all applications and resources to make them aware of the SDP solution and use a single version of it.
• Device limitations. Despite support for a lot of modern devices, it might be challenging to connect old routers or vendor-specific devices to SDP software.

As we can see, most SDP limitations concern implementation and availability. So in order to experience the benefits of a software defined perimeter, you need to be attentive during deployment. In the next section, we take a look at key deployment models for this technology.

SDP deployment models

A software defined perimeter can be deployed as a standalone on-premise product or as a cloud service. The choice between these deployment models depends on:

• the types of participants in the SDP network (only devices, only servers, or devices and servers)
• the load on parts of the network
• the types of services you need to provide to connected devices. 

There are four common types of SDP deployment models:

• Client–gateway
• Client–server
• Server–server
• Client–server–client

Let’s consider each of them:

Client–gateway

In this type of SDP model, an Accepting Host becomes a gateway to a protected server. This is the most common deployment model because it allows for creating a single host for several resources. There are two ways to deploy a client–gateway SDP:

1. Deploy a gateway and a server inside the protected network. This helps to mitigate lateral movement attacks, which include exploits, server scanning, and man-in-the-middle attacks.
2. Deploy a gateway and a server on the internet. This way, deployed servers will be isolated from unauthorized users and therefore better protected from attacks such as a denial of service, man-in-the-middle, SQL injection, operating system and application vulnerability exploits, password cracking, cross-site scripting, and cross-site request forgery.

Client–server

In the client–server model, a server protected by SDP functions as an Accepting Host. This type of deployment has a lot in common with the client–gateway model but is preferable in several cases:

1. You have only a few servers to protect and have the time to configure an Accepting Host for each of them.
2. The load on a certain server is too high. If you use a single Accepting Host for several high-load servers, it will affect the host’s operation speed.
3. Your server lacks elasticity.

Server–server

As the name suggests, this SDP model is used for server to server communications. In this model, servers are used as both Initiating and Accepting Hosts. You can deploy this model for servers that offer:

• Representational State Transfer (REST) services
• Simple Object Access Protocol (SOAP) services
• Remote procedure call (RPC) services
• APIs 

For example, if one of your servers runs a REST service, it will be the Accepting Host, and the server initiating the REST call will be the Initiating Host. An SDP controller secures these servers from unprotected access and lateral movement attacks. This type of SDP model helps to reduce server load.

Client–server–client

This SDP model allows for creating a peer-to-peer network in which clients can share their resources. Similar to the servers in the previous model, clients can be Initiating and Accepting Hosts. The SDP hides the IP addresses of connected clients. The client–server–client SDP model can be used to establish IP telephony services, video conferencing, etc.

It’s also possible to add a gateway to this configuration and transform it into a client–gateway–client model. Regardless of what deployment model you choose, let’s see how adding an SDP can benefit your operations.

Why do you need software defined perimeter network security?

Traditional network security relies on firewalls guarding a defined perimeter. However, as cloud applications and remote work become more and more popular, the network perimeter gets increasingly porous. Deploying an SPD can help you address this issue as it:

• Secures access to specific applications, not just the network. With an SDP, your app will have a better overall security posture. Even if attackers manage to breach your system, they won’t be able to access sensitive data unless they also compromise a specific application’s security.
• Adapts to the evolving threat landscape. As you use a zero-trust architecture, you make sure that only authorized users and devices can access resources throughout the session, regardless of their location or initial network access.
• Simplifies secure access for remote users. You can enable secure connections from anywhere without compromising security. Remote workers can access authorized applications without needing full access to the entire network infrastructure.

There are plenty of cases where you can leverage the benefits of an SDP. Let’s take a look at some of them.

SDP implementation use cases

SDP solutions are effective for networks of all types and sizes. They can be deployed on-premise, in the cloud, or in a hybrid environment. There are several use cases where SDPs have already proven effective.

• Secure cloud applications. An SDP model based on access rights can easily be extended beyond a traditional enterprise data center. An SDP offers equally protected connections when working with on-premise, cloud-based, and hybrid resources.
• DevOps activities. An SDP provides an isolated and controlled environment that enables DevOps engineers to isolate workloads, provide granular access to corporate resources, and control network activity.
• Privileged and third-party access. SDP software treats all users equally. Both ordinary and privileged users have to be identified by the SDP controller before acquiring access permissions. The procedure is the same for remote users. In this way, an SDP enforces need to know access with no need for a standalone solution.
• Simplified bring your own device (BYOD) access. BYOD is an extremely popular policy that allows employees to use personal devices for work. Usually, BYOD devices require strict access procedures because of security concerns. An SDP provides simple access for such devices (as it does for any other devices) and secures sessions on those devices.
• Network microsegmentation. Microsegmentation is the process of breaking a network into smaller pieces in order to make it easier to secure the overall system. It’s part of a zero-trust policy. In a software defined perimeter, each group of resources protected by one gateway or Accepting Host can be considered a network segment.

Conclusion

The software defined perimeter is a new but promising cybersecurity approach that can answer modern cybersecurity threats. As the traditional network perimeter becomes increasingly blurred, it gets easier for hackers to successfully penetrate it.

An SDP answers this threat by enforcing device authentication and user identification before providing network access. This way, enterprise resources are obscured from unidentified users. All connections inside a network protected by a software defined perimeter are encrypted and change dynamically. 

An SDP mitigates common security threats like DoS, credential theft, MITM attacks, server exploitation, and session hijacking.