Software-defined perimeter brings trusted access to multi-cloud applications, network resources

Many companies today have a hybrid approach to their networking and IT infrastructure. Some elements remain in an on-premise data center, while other portions have gone to the cloud and even to multi-cloud. As a result, the network perimeter is permeable and elastic. This complicates access requirements at a time when it’s more important than ever to enable accessibility while preventing unauthorized access to applications and data.

To reduce risk, some organizations are applying a zero-trust strategy of “verification before trust” by incorporating stronger, stateful user and device authentication; granular access control; and enhanced segmentation no matter where the applications and resources reside.

One implementation of a zero-trust strategy that is starting to gain some traction is software-defined perimeter (SDP). SDP is a defined architecture by the Cloud Security Alliance. SDP has been around for several years now and has primarily been used to protect cloud-based or SaaS applications and data. Pulse Secure recently announced an SDP solution for hybrid IT, which should make it more attractive to enterprises that have a diverse infrastructure.

How a software-defined perimeter works

The notion of a software-defined perimeter is to establish trust closest to the resources involved. That means establishing trust at the entity making the request for access, as well as establishing trust at the application or network resource that is to be accessed. Several distinct components are needed to establish this trust and to ultimately make the desired, secured connection.

The first component is a client that wants to gain access to an application or other resource (an entity). A key security feature is that the entity has no DNS entry, so it’s hidden and can’t be reached directly. Instead, the client has an SDP-enabled agent or agentless means to communicate with the second component, an SDP controller that holds the security policy and arbitrates all the connectivity between end user and Internet of Things (IoT) devices and the hidden entities. The controller has a finite list of users who are trusted and authorized, as well as a list of devices that are registered.

The controller communicates with the client to understand who the user is and the security state of the device. This information is checked against a roles-based access control and resource policy managed by the controller, which inherently interfaces with the enterprise identity management system. If everything checks out, the controller communicates and authenticates with the third component of the solution, an SDP gateway located close to the target entity. 

Following an exchange of security certificates, the controller securely informs the gateway that it will receive an authenticated communication from the client. The controller securely informs the client how to establish secure communication directly to this gateway. Next, the client and the gateway authenticate and establish their secure communication, which in turn creates a direct connection to its desired entity. See below for an illustration of this architecture.

Cloud Security Alliance

Of course, an end user is unaware of this complex process. All they know is that they follow their regular procedure, whether on their PC, tablet, smartphone or browser, to gain access to their application or resource, and all the complex validations and authentications take place in the background.

The SDP architecture can create very granular segmentation of access to specific applications and resources, whether they are on-premise or public or private cloud. Because the target entities are hidden and anyone or anything wanting to access them has to be validated by the controller, there is a reduced threat surface. Malware, credential theft, man-in-the-middle and internal network attacks are basically shut down because they can’t move laterally or even north-south without the appropriate security certificates and secret handshakes.

Software-defined perimeter use cases

Here are just a few use cases for SDP in the enterprise:

• Simplified access for BYOD – Direct, secure, and easy access to cloud applications or resources directly from users’ devices of choice
• Third-party and privileged user access – Enable third-party and privileged access to critical systems from anywhere but with granular control per application or resource
• Application or network segmentation – Further reduce malware propagation and attack surface inside data center and cloud environments
• DevOps – Dynamic provisioning of secure access to enable DevOps user access to key resources and to isolate workloads

Today, some SDP products, such as zScaler, are offered as a cloud service where the SDP controller is hosted outside the enterprise, requiring access requests, policy, identity and entity interaction to go through their hosted service to enable cloud access. Many organizations can’t or prefer not to have controls and routing go through a third party for cloud access.

Pulse Secure has made SDP available as part of its broader Secure Access platform, which also supports various modes of VPN (e.g., always-on, on-demand, per app, and mobile device), NAC, and mobile security. SDP is a complementary offering that allows customers to choose which access control measure(s) work best for them. New or existing Pulse Secure customers with the Advanced or Enterprise Suite can activate SDP with the flick of a license key.

The Secure Access platform enables centralized policy management, interoperability, scalability, the ability to do data center or multi-cloud, and the ability to do load balancing and security of the application. Zero trust is a key tenet within the entire Secure Access platform, regardless of which approach – SDP, VPN, NAC – is utilized.