In the physical world, the outer edge of the perimeter is protected by trenches, fences, or walls, and incomers are checked at entry points. In a virtual network, firewalls traditionally protect the perimeter, and static policies validate users and grant them access.
Additional tactics protect sensitive resources from malicious intruders who evaded detection based on policies.
This strategy worked reasonably well in a static environment, where data and critical resources where typically siloed on-premise. In a multi-cloud-based environment accessed by a mobile workforce expecting to connect from anywhere, at any time and from any device, this model is unsustainable.
The new reality led to the advent of Zero Trust Security, an architecture designed for today's cloud-based networks.
The most advanced Zero Trust architecture today is that of a Software-Defined Perimeter (SDP). In an SDP, unlike in the previous resource and data-centric perimeter, security measures are focused on individual users and their devices.
Both users and devices are monitored, and even a trusted user on a trusted device needs to be verified each time they connect and then only gains access to a micro-segmented part of the network, and for a single session.
The verification process comprises both a human and a machine element so that both the user and the device are verified. The human verification steps require the user to confirm their identity through authentication and their privileged access level through authorization.
However, validating the human user is not enough. As the device has access to the Software Defined Network (SDN), it is integrated with the SDP and needs to be verified as well. This is done through machine verification. A trusted user trying to connect from an untrusted device is denied access to the requested resources.
When both the user and the device are verified, SDP defined policies calibrate the user connection based on privilege access level, always established on a need-to-know basis, capping the privilege level to the lowest level available for that user/device pair and limiting access to a single resource, preventing lateral movements.
An SDP comprises three main components:
The SDP Client is a software installed on each endpoint included in the perimeter. The SDP client functions include device verification and tunnel setup.
The device verification features themselves vary between SDP vendors.
It configures a Transport Layer Security (TLS) connection between the SDP Client and the SDP Gateway. This encrypted tunnel performs two functions
The SDP Gateway is the last check before gaining access to the requested resource. Located as close s possible to the requested resources, it confirms with the SDP Controller that the client is authorized, validated, and verified and can be granted access to the resource for the requested session.
When receiving confirmation, the gateway allows the connection to the application.
Unlike a MAC connection that stops at layer 2, the SDP controller and gateway cover all layers up to layer 7.
How would that work in real life?
SampleCompany is provisioned with an SDP, and all their employees’ devices have been updated.
Their sales agent, Sidney, needs to access the SalesManagementApp from his mobile. He taps on the app to connect, sending a Single Packet Authorization (SPA) that includes an encrypted key.
With its Public Key Infrastructure (PKI), the SDP Controller checks the key. As the key is correct, it identifies and authenticates Sidney.
If the controller PKI confirms Sidney’s identity and his mobile’s integrity, the SDP Controller creates an encrypted tunnel between Sidney’s mobile and the SDP Gateway. The gateway then allows Sidney’s mobile to access the SalesManagementApp.
Yet, even though SalesAnalyticsApp resides on the same server as SalesManagementApp, and Sidney has the required privileges to access it, he will have to undergo the same process to access SalesAnalyticsApp.
During the entire time Sidney’s mobile is connected to SalesManagementApp, communication between the SDP Client and the SDP Gateway continues. If at any time Sidney's mobile is compromised during that connection, the connection is severed, and the malicious actor who had penetrated Sidney's mobile is locked out of the entire SDP.
If a client's key is compromised or invalid, its connection is immediately blocked off, and all visibility to applications on the network is cut off. If a machine is showing signs of being compromised, it would no longer be considered trusted and would be immediately cut off from the network and from access to any resources.
The entire goal of SDP is to prevent network attacks against applications, but there are several other advantages to using SDP in your network, including :