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. Gartner predicts that by 2021, 60% of enterprises will phase out network VPNs in favor of software defined perimeters.
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.
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.
A software defined perimeter architecture consists of two components:
- 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.
- 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.
Various software defined perimeter vendors offer different types of solutions, but generally, an SDP workflow looks like this:
- 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.
- 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.
- 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.
- The Initiating Host establishes an encrypted VPN connection to the Accepting Host.
As we mentioned, there are various ways to implement an SDP. In the next section, we take a look at key deployment models for this technology.
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:
Let’s consider each of them:
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:
- 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.
- 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.
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:
- You have only a few servers to protect and have the time to configure an Accepting Host for each of them.
- 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.
- Your server lacks elasticity.
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
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.
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.
All of the deployment models described above share the same benefits and drawbacks.
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.
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.
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.
At Apriorit, we’ve developed a lot of different network management systems, including SDP solutions. Feel free to contact us and start discussing your project!