Don’t Be Fooled By ‘Lowercase sdp’ Imitators

SDP stands for Software Defined Perimeter, and is a set of specific requirements defined by the Cloud Security Alliance (CSA). The CSA adopted the US Department of Defense’s (DOD) methodology used to protect top secret and classified data systems, and released the first specifications in 2014.

SDP is gaining rapid traction as a new and agile way to implement the Zero Trust concept by providing secure access for any user, any device, any resource, or any location on any network connection. There is so much market traction that many vendors are renaming their old legacy products as “SDP” or launching a new product they call “SDP,” in the hopes of capturing market share.

For now, let’s call these imitators “lowercase sdp.” For solutions that adhere to and/or exceed the CSA specifications, let’s call those “Capital SDP” solutions.

Enterprises are increasingly phasing out network VPNs in favor of SDP. But a Capital SDP can do a whole lot more than just VPN replacement, but I will save that for another blog.

Capital SDP is the foundation of Zero Trust because it secures network access between people and devices that access data and workloads. But not all SDPs have such robust capabilities. There are a lot of vendors that claim to be Capital SDP but are in actuality lowercase sdps. So, what constitutes a genuine Capital SDP solution, and what is merely an imitation?

What a Capital SDP is Not

First, it’s important to understand what an SDP is not. There are many lowercase sdp security solutions on the market claiming to be Capital SDP, but if you see a solution that requires other products, or bolt-on technology, this “solution” doesn’t adhere to the CSA specifications. A lowercase sdp would be a product that doesn’t implement the most important layers of the security controls outlined in the specifications, such as:

• Single Packet Authorization (SPA)
• Mutual Transport Layer Security (mTLS)
• Device Validation (DV)
• Dynamic Firewalls

These are the things that the DOD first combined to protect and secure access to top secret and classified systems. In an event dubbed a “Hackathon,” the CSA challenged the security community to bypass these layers for an all-expenses-paid trip to Black Hat and DEFCON. Hackers sent 10 billion packets attempting to penetrate the network, but no one was able to circumvent even the first layer of SDP security controls – the single packet authorization protocol.

What a Capital SDP is

A Capital SDP is a solution that adheres to and/or exceeds the CSA specifications. It doesn’t require any legacy access machinations, or any secondary products to be bolted on to make up a whole secure network access solution. Software Defined Perimeter is a paradigm shift from the traditional corporate security methodology, but one with vast security benefits. If it is used to secure top-secret infrastructure for the US military, and hackers couldn’t break into it after billions of attempts, it is worth considering.

A Capital SDP offers enterprises three important functions that many lowercase sdp solutions do not:

Single Packet Authorization – A Capital SDP solution uses SPA. Username/password combinations provide transferable device access opportunities that are inherently insecure and should be avoided. SPA essentially cloaks the entire external attack surface turning it into a “black cloud,” meaning the infrastructure cannot be detected. This provides an inherent level of protection against Man-in-the-middle (MitM), OWASP Top 10 attacks, and Distributed Denial of Service (DDoS) attacks.

Mutual Authentication – TLS, or Transport Layer Security, in its simplest form, is a set of protocols to create a secure communication channel between two computers or applications across a network. TLS is traditionally one-way, where a client authenticates to a server to establish a secure channel. Mutual TLS or mTLS goes one step further. It requires two-way authentication, where both parties must authenticate to each other, eliminating the threat from many types of MitM attacks. As the CSA specifications state: “The connections between all hosts must use … mutual authentication to validate the device as an authorized member of the SDP prior to further device validation and/or user authentication.”

Decoupling of Control and Data Channels – Another brilliant part of the original DOD framework was the separation of the control plane from the data plane. This was also adopted as part of the CSA specifications. This is similar to the terms Policy Decision Point (PDP) and Policy Enforcement Point (PEP).

As the CSA specification state: “… the architecture of the SDP consists of two components: SDP Hosts and SDP Controllers. SDP Hosts can either initiate connections or accept connections. These actions are managed by interactions with the SDP Controllers via a secure control channel. Thus, in SDPs, the control plane is separated from the data plane to enable a completely scalable system.”

Figure 1: The architecture of the Software Defined Perimeter consists of two components: SDP Hosts and SDP Controllers. Source: Cloud Security Alliance

In the SDP authentication process, the “Controller” is the control channel (or PDP) for authenticating access. The Accepting Host that acts as a “Gateway” is the data channel (or PEP), from which access is granted or denied.

This is an important distinction from other lowercase sdp approaches claiming to adhere to the Capital SDP model. This separation keeps your gateway-protected resources fully invisible to prying eyes. When the controller successfully authenticates the initiating host, it passes a list of approved entitlements in an encrypted token via encrypted mTLS tunnel. Only then can the initiating host “see” the gateway resources and be connected via the data channel. That initiating host can only see the specific resources they’re authorized to see, preventing lateral movement if the device is compromised. Lastly, the controller continuously monitors for context, policy and environmental changes to add or revoke any entitlements.

A Software Defined Perimeter provides enterprises with a solution for securing access across hybrid environments for the agile modern workforce. Single Packet Authorization, mutual TLS and separate control & data channel functionality are essential to a Capital SDP.

To learn more about SDP, download The Definitive Guide to a Software-Defined Perimeter that will help you understand additional benefits and use cases for your organization.