Software-defined perimeter

The traditional enterprise network architecture is based on the premise of creating an internal network that is separated from the outside world by a fixed perimeter, typically consisting of firewall functions. These firewalls block external users from accessing the internal network while allowing internal users to connect to external resources.^[3] Traditional fixed perimeters help to protect internal services from external threats. This is achieved by blocking external visibility and access to internal applications and infrastructure. However, the weaknesses of this traditional fixed perimeter model are becoming increasingly problematic due to the widespread use of user-managed devices and phishing attacks, which provide untrusted access inside the perimeter. Additionally, the rise of SaaS and IaaS has extended the perimeter into the internet.^[4] Software-defined perimeters address these issues by allowing application owners to deploy perimeters that maintain the traditional model's value of invisibility and inaccessibility to outsiders, while being deployable anywhere—on the internet, in the cloud, at a hosting center, on a private corporate network, or across some or all of these locations.^[1]

There are several techniques for delivering a software-defined perimeter (SDP). These include:^[5] ======

• Single Packet Authorization (SPA) uses proven cryptographic techniques to make internet-facing servers invisible to unauthorized users. Only devices that have been seeded with the cryptographic secret can generate a valid SPA packet and, as a result, establish a network connection.^[6]
• First Packet Authentication involves a single-use, cryptographically generated identity token inserted at both ends of a TCP/IP session for authentication. If the request is allowed, the gateway applies a security policy forward, redirects, or discards, based on the identity.
• Authenticate Before Connect ensures that endpoints are provisioned with unique, cryptographically generated identities (commonly using X.509 certificates and JSON Web Tokens). These endpoints establish outbound connectivity into a mesh overlay that only "listens" for authenticated and authorized endpoints. This approach ensures that both the source and destination never require inbound connectivity and can work even in challenging NAT scenarios.

In its simplest form, the architecture of the Software-Defined Perimeter (SDP) consists of two components: SDP Hosts and SDP Controllers. SDP Hosts can either initiate or accept connections. Interactions with the SDP Controllers manage these actions through a control channel (see Figure 1). As a result, the control plane is separated from the data plane in a Software-Defined Perimeter, enabling greater scalability. Additionally, all components can be made redundant for higher availability.

 

The SDP framework has the following workflow (see Figure 2):

1. One or more SDP Controllers are brought online and connected to the appropriate authentication and authorization services (e.g., PKI, device fingerprinting, geolocation, SAML, OpenID, OAuth, LDAP, Kerberos, multifactor authentication, and other similar services).
2. One or more Accepting SDP Hosts are brought online. These hosts connect to and authenticate with the Controllers. However, they do not acknowledge communication from any other host and will not respond to any non-provisioned requests.
3. Each Initiating SDP Host that comes online connects to and authenticates with the SDP Controllers.
4. After authenticating the Initiating SDP Host, the SDP Controllers determine a list of Accepting SDP Hosts with which the Initiating Host is authorized to communicate.
5. The SDP Controller instructs the Accepting SDP Hosts to accept communication from the Initiating SDP Host and applies any optional policies required for encrypted communications.
6. The SDP Controller provides the Initiating SDP Host with the list of Accepting SDP Hosts and any optional policies required for encrypted communications.
7. The Initiating SDP Host establishes a mutual VPN connection with all authorized Accepting SDP Hosts.

 

While the general workflow remains the same for all implementations, the application of SDPs can favor certain implementations over others.

In the Client-To-Gateway implementation, one or more servers are protected behind an Accepting SDP Host, which acts as a gateway between the clients and the protected servers. This implementation can be used within an enterprise network to mitigate common lateral movement attacks, such as server scanning, OS and application vulnerability exploits, password cracking, man-in-the-middle attacks, Pass-the-Hash (PtH), and others.^[7][8][9] Alternatively, it can be implemented on the internet to isolate protected servers from unauthorized users and mitigate attacks like denial-of-service, OS and application vulnerability exploits, password cracking, man-in-the-middle attacks, and others.^[10][11]

The client-to-server implementation offers features and benefits similar to the previously mentioned Client-To-Gateway implementation. However, in this case, the protected server runs the Accepting SDP Host software, rather than using a gateway in front of the server running that software. The choice between the Client-To-Gateway and Client-To-Server implementations is typically based on factors such as the number of servers being protected, load balancing methods, server elasticity, and other topological considerations.^[12]

In the Server-To-Server implementation, servers offering a Representational State Transfer (REST) service, a Simple Object Access Protocol (SOAP) service, a remote procedure call (RPC), or any kind of application programming interface (API) over the internet can be protected from unauthorized hosts on the network. For example, in this case, the server initiating the REST call would be the Initiating SDP Host, and the server offering the REST service would be the Accepting SDP Host. Implementing an SDP for this use case can reduce the load on these services and mitigate attacks similar to those mitigated by the client-to-gateway implementation.

The Client-To-Server-To-Client implementation creates a peer-to-peer relationship between the two clients and can be used for applications such as IP telephony, chat, and video conferencing. In these cases, the SDP obfuscates the IP addresses of the connecting clients. As an alternative, a user can opt for a Client-To-Gateway-To-Client configuration if they wish to hide the application server as well.

For data breaches involving intellectual property, financial information, HR data, and other sensitive data exclusively available within the enterprise network, attackers may gain entry by compromising a computer on the network and then moving laterally to access high-value information assets. In this scenario, an enterprise can deploy an SDP inside its data center to partition the network and isolate high-value applications. Unauthorized users will be denied access to the protected application, thereby mitigating the lateral movement on which these attacks depend.^[13]

The Software-Defined Perimeter (SDP) model, traditionally used to secure physical infrastructures, is also adaptable to private cloud environments, offering flexibility and scalability. Enterprises can use SDPs to secure public cloud instances, either in isolation or as part of a unified system that spans private and public clouds, as well as cross-cloud clusters.

For Software-As-A-Service (SaaS) providers, SDPs enhance security by designating the service as an Accepting Host and all users as Initiating Hosts. This configuration allows SaaS vendors to leverage the internet's global reach while reducing exposure to potential threats.

Infrastructure-As-A-Service (IaaS) providers can offer SDP-as-a-Service, providing customers with a secure on-ramp to their cloud infrastructure. This mitigates various attack vectors while enabling customers to benefit from IaaS agility and cost savings.

Platform-As-A-Service (PaaS) providers can integrate SDP architecture into their offering, providing an embedded security solution that mitigates network-based attacks.

As a growing number of new devices are connected to the Internet ^[12], back-end applications that manage these devices and/or extract information from them can become mission-critical, acting as custodians for private or sensitive data. SDPs can be used to conceal these servers and their interactions over the internet, thereby enhancing security and uptime.^[14]

• Advanced Encryption Standard
• Global Information Grid
• IPsec
• Public-key infrastructure
• Transport Layer Security

• Cloud Security Alliance “Introduction to the Software Defined Perimeter Working Group”
• Article from GCN - 1105 Public Sector Media Group "Black Cloud Darkens the Enterprise to all but Authorized Devices"
• Article from Light Reading - "Verizon and Vidder put SD-Perimeter around Enterprise Security"
• Article from CSO - "Goodbye NAC. Hello, software defined perimeter"
• IEEE "Software-Defined Perimeters: An Architectural View of SDP"
• Article from ComputerWeekly - "Gas distribution network SGN invests in software-defined perimeter"
• Moubayed, Abdallah; Refaey, Ahmed; Shami, Abdallah (October 2019). "Software-Defined Perimeter (SDP): State of the Art Secure Solution for Modern Network". IEEE Network. 33 (5): 226–233. doi:10.1109/MNET.2019.1800324. S2CID 189892671.