Software Defined Perimeter Explainer

Graham Thompson   ·   Tuesday, July 25th, 2023

Introduction

Cloud Security Alliance (CSA) originally created the Software Defined Perimeter (SDP) specification way back in 2014. The goal of this entry is to discuss the CSA viewpoint of what SDP is all about.

What is Software Defined Perimeter (in one sentence)?

At a very high level, SDP granularly restricts access to resources based on both device and user authorization.

SDP Analogy

In a CSA video simply titled “Software Defined Perimeter”, the co-chair of the CSA SDP working group likens SDP to TSA pre-check. When someone applies to the Trusted Traveller program, the TSA verifies the traveller’s information and issues them a trusted traveller id number (think Global Express or Nexus card). When booking travel, the traveller enters their trusted traveller ID. When they print their plane ticket, they have “TSA Pre-check” printed on their ticket which allows them to use expedited security lanes. This form of pre-check is likened to having a multifactor authentication at the beginning of a connection. By the way, this comes up later in this entry, so remember the trusted traveller ID discussion.

Why SDP Works

SDP reverses the traditional networking approach of “connect first, authenticate after” inherent in TCP/IP. With the SDP approach, you are authenticating the device and user first, then allowing for connection to be available (and the resource even being seen). This fundamental change in approach is a key reason why SDP is needed for organizations in a hybrid cloud world.

What are Black Networks?

In DoD-speak, a black network is a network that isn’t visible to unauthorized users. This is what the SDP does. An unauthorized user cannot even see the servers and services that are behind an SDP gateway until they are authorized to see them. In fact, every user gets their own perimeter established based on their own context. These are implemented in the form of policies established at the SDP Controller. This perimeter is dynamic and contextual. This means each access request is evaluated.

Talk about a Need to Know approach to security!

What does this mean from a security perspective? Say a user clicks on a phishing link and is compromised. The attacker will have access to a subset of resources from the start. They won’t even be able to see resources the user isn’t given permission to see in the first place. This is a complicating factor for the attacker as they can’t see any resources of interest, so they don’t even know they exist.

SDP Components

There are three software components in an SDP architecture. These are:

• An SDP client. This is installed on the device that wants to access a resource. The agent itself also monitors for Indicators of Compromise at the workstation level.
• An SDP Controller. This acts as a Policy Decision Point (PDP). It works with the enterprise Identity Provider Service (IdP). This authentication could be based on Active Directory, SAML, or many other forms of authentication. The PDP generates access tokens.
• An SDP Gateway. This acts as the Policy Enforcement Point (PEP). The PEP consumes access tokens generated by the SDP Controller. The gateway also operates as a layer 7 firewall so it can enforce very granular entitlements.

The following architecture image from the CSA Guidance (v4) shows the SDP components

Software Defined Perimeter Process

When the client is first initialized, a 64 bit string is sent from the SDP controller to the client device. This is then used to create an access token for subsequent connections. This is referred to as pre-authentication (the “trusted traveller number” in our earlier TSA analogy). This performs the trusted device part of SDP. Without the token, the device will not be trusted. No trust equals no access.

Device validation is then performed. This can also test to determine if the device meets security standards such as OS in use, patch levels and the likes.

When the user logs on, the credentials are passed to the SDP controller which then forwards them to the IdP for validation. The controller then learns of the roles (groups) the user is a member of.

After the authentication is performed, the controller looks up what applications the roles have access to and sends the SDP gateways a list of resource authorizations and a list of SDP gateways to the client. This allows the client to make secure VPN-like dynamic connections to resources where all communications are encrypted. This allows for secure client-gateway connections regardless of location. You can think of this as a client VPN connection to the SDP gateway.

Continuous monitoring is also performed. Access can be revoked at any time if a threat is detected (for example, the client agent determines the workstation has indicators of compromise.

How is this different than Zero Trust Network Access?

It isn’t. SDP is the foundation of Zero Trust Network Access (ZTNA).

What about SDP do I need to know for my CCSK Exam?

As covered already, the Cloud Security Alliance created the SDP specification, so chances are good they’ll test you on it. Page 82 of the CSA Guidance v4 has everything you need to know about SDP for the CCSK exam. It is also addressed in CCSK training. In fact, this blog goes beyond what is covered in the guidance. If you understand the content here, you’ll be able to answer anything they throw at you as part of the exam.

What about SDP do I need to know for my CCSP Exam?

The Official ISC2 CCSP student guide (and associated training) doesn’t address SDP at all. If it’s not covered in the official curriculum, it’s likely not going to be on the exam.