Software Defined Perimeter

What is Software Define Perimeter technology?

Software Defined Perimeter (SDP), also called a “Black Cloud”, is an approach to computer security which evolved from the work done at the Defence Information Systems Agency (DISA) under the Global Information Grid (GIG) Black Core Network initiative around 2007.

Software-defined perimeter (SDP) framework was developed by the Cloud Security Alliance (CSA) to control access to resources based on identity. Connectivity in a Software Defined Perimeter is based on a need-to-know model, in which device posture and identity are verified before access to application infrastructure is granted. Application infrastructure is effectively “black” (a DoD term meaning the infrastructure cannot be detected), without visible DNS information or IP addresses.

The inventors of these systems claim that a Software Defined Perimeter mitigates the most common network-based attacks, including server scanning, denial of service, SQL injection, operating system and application vulnerability exploits, man-in-the-middle, pass-the-hash, pass-the-ticket, and other attacks by unauthorized users.

How can this technology help you?

A software-defined perimeter (SDP) is a way to hide Internet-connected infrastructure (servers, routers, etc.) so that external parties and attackers cannot see it, whether it is hosted on-premises or in the cloud. The goal of the SDP approach is to base the network perimeter on software instead of hardware. A company that uses an SDP is essentially draping a cloak of invisibility over their servers and other infrastructure so that no one can see it from the outside; however, authorized users can still access the infrastructure.

A software-defined perimeter forms a virtual boundary around company assets at the network layer, not the application layer. This separates it from other access-based controls that restrict user privileges but allow wide network access. Another key difference is that an SDP authenticates devices as well as user identity. The Cloud Security Alliance first developed the SDP concept.

Challenges

It also greatly reduces the attack surface where you do not have any open ports. Therefore, a malicious user cannot cause denial of the service, and they cannot even connect. However:

One of the biggest challenges with an SDP approach is the out-of-band controller, which doesn’t sit in the actual data path after the initial authentication request is completed.

Consider a situation where a user connects to an enterprise app. After initial authentication and authorization through an SDP controller, the client or IH is going to establish a tunnel with application services via SDP gateways, based on the policies and port numbers. If the same user gets infected with malware, it can easily spread to other applications via on-demand open ports. It can exploit known application vulnerabilities that this device is authorized to access simply because the AH or gateway has no knowledge or intelligence to block the request inside the tunnel.

I believe SDP is a modern form of client-based VPN that adds identity verification and policies before the user connects to any services, but it does nothing for service insertion, application performance, or truly “SaaSify-ing” enterprise applications. In addition, customer firewalls still need to be configured to accept inbound connections and allow traffic from the SDP gateways. Firewall rules introduce complexity, holes in the perimeter, and added IT maintenance.

The more sophisticated approach is to use an identity aware proxy (IAP) in building Zero Trust as your Next-Gen Access model. This not only authenticates and authorizes users/devices, but the application requests can be terminated and inspected, and it allows granular application-level access controls, not firewall rules. Therefore, configured policies can reflect user and application intent, not just ports and IPs. Because this is a proxy model, you have the flexibility to layer on services like web application firewalls, bot protection, DLP, and acceleration (CDN).

Advantages

With an SDP, it should not be technologically possible to connect with a server unless authorized to do so.

SDPs allow access to users only after:

           1) verifying user identity, and

           2) assessing the state of the device.

Once the user and device are authenticated, the SDP sets up an individual network connection between that device and the server it is trying to access. An authenticated user is not logged into a larger network, but rather is given their own network connection that no one else can access and that only includes the services that the user has approved access to.

Imagine a web server that is connected to the Internet but does not open connections with anything. It does not accept requests or send responses; it has no open ports and no network access even though it is plugged into the Internet (somewhat like a toaster or a lamp that is plugged into a wall outlet but turned off so that electricity does not flow through it). This is the default state for servers inside a software-defined perimeter.

Another way to think of SDPs is to imagine a front door that is always kept locked. No one can come through the door, or even look inside, until the person on the other side of the door verifies who the visitor is and what they are doing. Once the visitor is allowed inside, the person in the house locks the door again.