Software Defined Perimeter - Everything You Ever Wanted To Know About

Since cloud storage has become more commonplace in the modern day, there has been an increased risk of cyber-attacks on these cloud systems due to the fact that cloud servers cannot be protected by traditional perimeter security measures.

So, what is SDP all about?

One of the ways that you can create a zero-trust architecture within your organization, is to create or use an SDP. We’ll be looking at what an SDP is, so you can do just that.

Since cloud storage has become more commonplace in the modern day, there has been an increased risk of cyber-attacks on these cloud systems due to the fact that cloud servers cannot be protected by traditional perimeter security measures.

This led to the creation of Software Defined Perimeter in 2013. Software Defined Perimeter is a research working group, their key focus is to create a security system that can help to prevent attacks on cloud systems. 

Any findings from their research will be made free to use for the public and will not be subject to any usage fees or any other restrictions.

From the inception of the working group, they decided to try and focus on building a security solution that is cost-efficient, but still incredibly flexible and effective. During their work, the team identified three key design requirements. 

Firstly, they decided that their security architecture would need to confirm the ID of the user, what device they are using and the permissions they have to access certain directories.

Next, the decided that verification using cryptography would be the best option to ensure their security protocol would be applied. Finally, it was decided that the tools required to achieve the first two requirements are security tools that have a proven track record and are in the public domain.

SDP came to the decision that their security architecture should be based on a control channel. This control channel would make use of standard components which the team thought would be best suited for the task. These components were SAML, PKI, and mutual TLS.

The working group eventually published a paper based on this idea to gauge whether or not there was a demand for such a system. This is where they named it Software Defined Perimeter.

There was a lot of interest in the work that SDP was doing and this led to the release of Version one of their systems during April 2014. 

Their first ever design was made up of an Initiating Host, which would give the Controller information on what device is being used and by who. This information would be transmitted along a mutual TLS connection.

Once this is done, the controller will link up to an issuing CA to confirm the identity of the device and will also link up to an ID provider so that they can verify the user’s identification.

After this information has been confirmed, the controller will provide either one or a number of mutual TLS connections, these connection(s) will link the previously mentioned Initiating Host and any required Accepting Hosts.

This system works to great effect, being able to prevent any strain of network attack including, Man-in-the-Middle, DDoS, and Advanced Persistent Threat.

(Image source: https://www.appgate.com/blog/software-defined-perimeter/what-is-a-software-defined-perimeter)

Architecture of SDP Version One
The original SDP products for commercial use was implemented using an overlay network for business applications, examples of these are remote access to high-value data, or to protect the cloud system from attacks. The Initiating Host for the SDP took the form of the client and the Accepting Host became the Gateway.

SDP Client
The SDP Client itself is responsible for a large variety of functions. Two of these include verifying the device being used and the user ID that is being utilized, as well as the routing of whitelisted applications to protected applications that have been authorized. 

The SDP Client has a real-time configuration to make sure that the mutual TLS VPN connection is only linked to items that the individual user is authorized to use.

This means that the SDP Client serves the function of placing restrictions on access to certain data points based on the user’s level of authority. This is carried out after the user’s ID and device have both been verified. 

SDP Gateway
The SDP Gateway serves as the point where the Mutual TLS connection to the SDP Client is terminated. In a topological sense, the Gateway will be implemented to be as close to the protected application as is practical.

The SDP Gateway will receive the IP address and their Certificate, once the identity of the device requesting access has been confirmed and their level of permission has been brought to light. 

SDP Controller
The SDP Controller serves the function of a trusted middleman between the backend security features such as the Identity Provider and the Certificate Authority to the SDP Client itself. Once the SDP client has achieved verification and the level of authority for the user has been examined, the SDP controller will then begin to configure the SDP client and the SDP Gateway so that they can establish a real-time connection through a mutual TLS.

(Image source: https://www.kernel-sesias.net/software-defined-perimeter-brings-trusted-access-to-multi-cloud-applications-network-resources/)

Security Properties of SDP’s Architecture
When you correctly implement all three of these features, the SDP architecture can provide great and unique property for your security system. These features are listed below.

1) Hiding Information
There is no DNS information, nor are there any visible ports within protected application infrastructure. Because of this, assets that are protected by SDP are called “dark” assets because they cannot be discovered, even if you scan for them.

2) Pre-Authentication
The identity of the device attempting access will always be verified before they are granted a connection. The identity of the device will be confirmed using an MFA token which will either be embedded in the TCP or the mutual TLS architecture.

3) Pre-Authorization
Users in an SDP system are only given access to servers that they need to access because of their role. The system used to confirm identity will communicate the authorizations of the user to the SDP Controller. This is carried out using a SAML assertion.

4) Application Layer Access
Even when a user is granted access to the application, this will only be on an application level and not on a network level. The SDP will also whitelist certain applications on the device that the host is using, which helps to keep system communications on an app-to-app level.

5) Extensibility.
The architecture of SDP is created on the back of various different standards-based parts. These include mutual TSL, SAML, and Security Certificates. Due to being made up of standard-based parts, the SDP architecture can easily be linked and integrated with other types of security systems, including data encryption systems and remote attestation systems.

Through the combined use of pre-authentication with pre-authorizations businesses can create networks that are invisible to unidentified hosts, whilst only providing the essential permissions to known-users, based on their organizational role.

One of the key parts about SDP is that the pre-authentication and pre-authorization need to occur before a TCP connection is granted between the user and the protected application.

As well as this, authorized users will only be granted permissions for certain applications to ensure that compromised devices cannot move laterally across the network.