By Parthasarathi Chakraborty
SDN, SDWAN & SDP have frequently encountered terminologies to the technology professionals these days. It is necessary to understand each of these terms before making any technology purchase decision. As a security executive, I was confused when I first encountered these concepts. I thought it will be a good idea to pen down some of the differences and utilities of these technologies for a focus on SDP and prework needed by the organizations for successful adoption.
What is SDN or SDWAN?
SDN or software-defined networking is a concept that isolates the control plane or brain of the networking gear from the data plane resulting in faster, better and cheaper ways of corporate internetworking. Branch to headquarter connectivity used to require expensive T1 circuits, private MPLS cloud with classic networking. In today’s world with the advent of IaaS, PaaS and SaaS services, branches require to have multi-dimensional connectivity with corporate headquarter and cloud service providers. It requires intelligent and faster transport with a lower total cost of ownership. SDWAN or software-defined wide area networking came into picture which is a realization of SDN concepts. Regular routers are offloaded from routing, quality of service or intelligent intent-based networking decisions and focus purely on faster packets processing. SDWAN decouples networking control plane from data plane with a new and intelligent overlay network. Corporations no longer need expensive MPLS or T1 only circuits, can have a variety of transport including cable, LTE, 4G/5G connections over the internet for connectivity. SDWAN overlays decide routing, QoS and other intelligence where the underlying transport focuses on data delivery. SDWAN is faster, transport agnostic (MPLS/4G/LTE/Cable) and cheaper wide-area connectivity for organizations and SDP are needed to secure SDWAN connectivity.
What is SDP and how does it work?
SDP or software-defined perimeter is based on the concepts of SDN but focuses on eliminating the inherent security weakness of network-level connectivity by adhering to the concepts of ZTS or zero-trust security model. Classing network connectivity is based on a trust boundary, usually established by placing a firewall. Inside the firewall, resources are “trusted” and allowed to talk to each other in a more lenient fashion compared to entities from “outside” the firewall trying to connect to the resources “inside” the corporate network. This model used to work just fine but has become flawed today because the demarcation between the inside and outside networks is getting blurred. Cloud, big data, mobility is the driver for extending the organization’s boundary beyond corporate data centers into public space making it just impossible to have a demarcation. Without a defined boundary, the onus is on cyber folks to protect the resources regardless of the origin of the connection – be it “inside” or “outside” the corporate network. Zero trust security (ZTS) got prominence because of the new context where organizations can’t have a defined boundary. The core concept of ZTS is allowing communication on a “need to know” basis with overly restrictive access permissions. Only allow the application or services needed to run the application supporting a business process and take away unnecessary permissions. SDP accomplishes zero-trust security with an architecture that requires three components- SDP client, SDP controller, and SDP gateway. SDP controllers act as a brain and the central decision-making authority for allowing SDP clients on the remote branch or third-party networks to talk to the protected resources behind the SDP gateways in the corporate data centers. Remote computers running SDP clients can only connect to allowed and published applications on the corporate data center brokered through the controllers after the user is authenticated and authorized at the controller level and the device integrity along with other granular posture details like geolocation is validated. The flow of events will be the following;
- SDP gateway established a connection with the SDP controller through which it exchanges information about published applications in the corporate data centers and receives information about “screened” SDP clients before allowing the inbound connection
- SDP clients authenticate, authorize using PKI with the SDP controller, part of the process the device integrity is also validated with posture scan and footprint hash. Only when the user behind the SDP client is authenticated, authorized and the device carrying the SDP client is validated to have the right level of integrity, SDP controller provides SDP gateway IP address to establish connectivity.
- SDP client opens the tunnel with a remote SDP gateway and gets the access to allowed applications published for the client
Is SDP a buzzword or it comes with great benefits?
Now we understand the SDP architecture, but the question becomes why do we need it in the beginning? It is a buzzword or a shiny-toy syndrome or it truly brings benefit to the organization? The short answer is SDP brings security benefits with a huge cost saving and reduces operational complexities by lowering the number of devices needed to manage for allowing a remote connection to the corporate hosted application. But what’s wrong with the classic remote access VPN or site to site VPN connectivity model? Basically, the classic connectivity requires a ton of appliances called VPN concentrators on the corporate headquarters to validate incoming requests from remote users or branches. After authentication and authorization, the remote user or branch lands on the “inside” network with a free pass to conduct reconnaissance since it gets an IP address of the inside “trusted” network. Any hacking attempt starts with the discovery of services or reconnaissance, if we can stop the discovery by only allowing access to the applications as opposed to assigning an IP that is routable inside the VPN concentrator then we can reduce the security risk to a greater extent. Applying the concepts of zero-trust security also allows us to validate the identity of the user or integrity of the computer of the connectivity request. Aside from security benefits, SDP is also a cost saver by eliminating the needs of keeping the stacks of VPN concentrators. The brain behind zero trust connection stays with the SDP controllers which are cloud-based services in most of the cases that can be scaled up or down at a fraction of the cost and the organizations need a few service provider owned SDP gateways in the corporate data centers resulting in a huge cost saving.
What considerations should be given before starting any SDP implementation?
First and foremost, SDP implementation requires a certain level of organizational maturity. On the surface, it sounds like a hassle-free switchover, more secure and cost saver remote connectivity solution but you may end up opening security holes unless you have a strong segmentation practice implemented in the corporate network. Implementing and upkeeping a micro-segmentation is a fair amount of work depending on the size of the organization. But why do we need a micro-segmentation solution for the secure adoption of SDP? Isn’t SDP supposed to bring more security to the environment? The answer is in the SDP architecture. The gateway is a piece of software provided, managed and maintained by the SDP vendor that is in the corporate datacenter. As explained in the previous section, SDP gateways initiate and always keep a connection open with the SDP controller. Even though the remote clients can only access applications allowed for remote consumption, the SDP agent can move horizontally in the corporate network and conduct reconnaissance or connect to any other server by exploiting loopholes and privilege escalation techniques. Unarguably it can only happen when the SDP service and the gateway are compromised. Since the gateway software is managed, operated and upgraded by the service provider where organizations don’t have any control or ability to implement standard software development life cycle process with security checks and balances – it is always advisable to not completely trust the SDP gateway and build a perimeter around its mobility. It is required to have a micro-segmentation implementation to ensure the SDP gateway can not move horizontally in case it is compromised and infect other systems with a wider blast radius.
To conclude, we can say that SDP certainly makes sense to adopt as a VPN replacement solution to reduce cost and improve security, but organizations should have a micro-segmentation implementation in place before deploying SDP.
About the Author
Parthasarathi Chakraborty CISSP, CCSP, CEH, CHFA, MS (Infosec -WGU), MS (Technology Management -Columbia University) Director – Infrastructure & Cloud Security Architecture. Currently at Bank of Montreal, previously with Guardian Life, JP Morgan, Bank of America & Merrill Lynch in Cyber Executive Leadership Roles
Member: Forbes Technology Council, Rutgers University Cyber Security Advisory Board, New Jersey Institute of Technology CSLA Advisory Board
