Architecture
Increased remote work, vulnerabilities popping up and the #killthevpn movement has the cyber security industry laser ...
Increased remote work, vulnerabilities popping up and the #killthevpn movement has the cyber security industry laser focused on the transition from VPN to SDP.
Let’s start with an acceptable definition of SDP from Wikipedia:
“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.”
Figure 1: SDP Flow
I hope we all can agree that the “ground truth" of SDP is valid and any organizations will benefit by adopting SDP architecture and principals(including Zero Trust). How is a Remote Access VPN any different than the “Client-to-gateway” deployment model defined for SDP?
“In the client-to-gateway implementation, one or more servers are protected behind an Accepting SDP Host such that the Accepting SDP Host acts as a gateway between the clients and the protected servers.”
Following the model, the VPN Headend is the SDP Gateway, and Radius Server(with advanced features, such as MFA/Passwordless, User/Device Trust verification, and least privilege policy assignment) is the SDP Controller.
The ""SDP Host initiates a mutual VPN connection to all authorized Accepting Hosts"" is a level of confirmation on the use of VPN as a core function of SDP. The main difference between an SDP Proxy or Gateway and a traditional RAVPN is going to get down to the practicality of application protocol support. Most SDP Gateways support modern protocols, such as HTTP/HTTPS, RDP, VNC, SSH, etc, whereas VPN allow for a tunnel of any IP-based traffic. Many organizations across the globe have applications that cannot run in a web browser using modern protocols (e.g. thick client that directly connects to a legacy workload/application).
While any security professional would agree that replacing aging infrastructure and applications should be a priority, status quo dictates that they haunt us for years to come. If an SDP architecture and strategy is dependent on modern protocols only, organizations could be missing out on some of the most important areas of risk reduction and attack surface. Often I see organizations tout their new shiny security tool without incorporating the 20-year-old application that is core to their business and could be hacked by a novice.
To top things off, there are marketing teams across the industry hoping they can provide a self-fulfilling prophecy, by trying to differentiate and drive a wedge between SDP vs VPN. “VPNs Cannot Support Zero Trust Security” or “SDPs are very different from VPNs” just sound silly to anyone who has spent the time to understand the inner workings of both solutions and deploy them. They would be much better off showing a traditional experience (admin or user) and how their solution provides a simpler, more efficient or additional functionality that didn't previously exist. Stop providing claims that aren’t backed by examples or proof points(proof is in the demo): I know a few people that preach this every day.
Final thought: If an organization cannot completely sunset their traditional IPSEC or SSL VPN, why wouldn’t the industry want to see them apply the same SDP(and zero trust) principals to that use case? I think this would be a fun debate topic."