21 Jun Software Defined Perimeter (SDP): The deployment
Deploying zero trust software-defined perimeter (SDP) architecture is not about completely replacing virtual private network (VPN) technologies and firewalls. By and large, the firewall demarcation points that mark the inside and outside are not going away anytime soon. The VPN concentrator will also have its position for the foreseeable future.
A rip and replace is a very aggressive deployment approach regardless of the age of technology. And while SDP is new, it should be approached with care when choosing the correct vendor. An SDP adoption should be a slow migration process as opposed to the once off rip and replace.
As I wrote about on Network Insight [Disclaimer: the author is employed by Network Insight], while SDP is a disruptive technology, after discussing with numerous SDP vendors, I have discovered that the current SDP landscape tends to be based on specific use cases and projects, as opposed to a technology that has to be implemented globally. To start with, you should be able to implement SDP for only certain user segments.
The traditional legacy VPNs and new SDP architecture will most likely co-exist side by side for a while. Therefore, if possible, you should opt for a solution that supports a dual-mode VPN and SDP architecture that is controlled within a single-pane-of-glass.
The types of SDP architectures
Various SDP architectures have different characteristics and are not identical to each other. But what’s important is to make the architecture available so that it’s easy for the customer to consume without too many changes, including opening up the new firewall ports. In such a scenario, there is a cloud-first SDP solution whereby the private cloud of a vendor is used to control the network resource access.
There are vendors that provide the SDP components, enabling you to implement in the cloud and on-premise locations. Then we have the infrastructure providers where you have to run all of their components to make things work. We also have an overlay option.
Finally, pure content delivery network (CDN) provides SDP solutions that require you to use their network delivery services. In this post, let’s discuss the SDP architecture where the vendor provides the components that allow you to implement yourself or with their professional service team. It is here some vendors follow closely the Cloud Security Alliance (CSA) SDP architectural guidelines while others do not.
A common SDP architecture consists of an SDP controller, client, and gateway components. The self-service compliance approach should give the option that allows both; the SDP and perimeter-based VPN functionality to work in parallel fashion, while still enabling the zero trust principles. You should aim to make sure that the new SDP components are easily integrated with the existing platforms and vendors already deployed.
The controller – the centralized policy enforcement engine
For centralized authentication and authorization, a controller component keeps track of the users, devices, and applications. The controller acts as the centralized policy enforcement engine that governs the control and data plane for all the users, devices, and applications.
The control plane offers features like granular segmentation i.e. you can get very specific, even to microsegmentation in context to per application, user or device. Everyone and everything that connects to the network will have a policy that governs where they can go, what they can see and do.
The controller keeps track and communicates with the entities triggering the authentication process. By doing so, the controller can determine which hosts can communicate with each other. The controller may relay information to external services such as attestation, geo-location, and/or identity services to determine its decision on what the requesting host can access.
A keynote about the controller is the type of integration points it can support. The SDP controllers should have the capability to connect and support the authorization services, for example, PKI, device fingerprinting, geolocation, SAML, OpenID, OAuth, LDAP, Kerberos, and multi-factor authentication.
The controller centralizes the policies and conducts an interface between the SDP client and the SDP gateway. This not only enables classification but also imparts the ability to push the policy out to the gateways that are located closer to the requesting client. Hence, one of the biggest gains is the visibility of who is on the network and where can they go. As discussed in one of the previous posts on SDP, today visibility is a major gap in enterprise networking.
We have a “dark” network as the end users do not have the ability to see IP or DNS entries of internal resources ( also enabling protection from a DDoS attack ). Then, based on the authentication and authorization set by the centralized controller and pushed to the gateways, the administrator is essentially turning the lights on.
The role of the gateway
The gateway can be a physical appliance or virtual machine (VM) positioned in the cloud accessible through a public clouds marketplace or located on-premise.
Ideally, the gateway can be established in the locations which are close to the requesting resource. The geolocation integration point is useful here in the sense that only certain locations can access the information due to security reasons or enhance the user experience by redirecting to the services that are logically closer.
It will be common to have users with multiple tunnels to multiple gateways, all at the same time. It’s not a static path or a one to one relationship but more of a user to application relationship. As a result, the applications can exist everywhere and anywhere whereby the tunnel is dynamic and ephemeral providing access to the protected assets. You could say that the gateway is a type of middleware device.
Once the user is authenticated and authorized to the controller, additional checks occur at the gateway. For example, SAML insertion can be used to authenticate the user which then passes the information to the SaaS-based offering.
There are policy and configurations located on each one of the gateways enabling the gateway to carry out endpoint validation stages. This makes sure that the endpoint is fulfilling the enforced posture assessment before access is granted to the network.