Zero Trust Network in the Cloud: From Traditional Security Perimeter to Software-Defined Perimeter

A security perimeter used to be the area inside a demarcation line separating the outside, deemed unsafe, or untrusted, from the inside, deemed safe, or trusted.

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:

• SDP client
• SDP controller
• SDP Gateway

The SDP Client

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.

• User and Entities Behavior Analytics (UEBA): monitors the endpoint or device for suspicious behavior that could indicate that it is compromised, and either requires additional authentication/verification or disconnects the device.
• Endpoint Detection and Response (EDR): monitors the endpoint or device for signs of threats and either neutralizes the threat or disconnects the device.
• Remote Browser Isolation (RBI): prevents attacks on the device by out locating all browser-based activity on an external interface. As the device separated from the browser, browser-based threats, including threats from malicious websites, are nullified.
• Sandboxing: an isolated testing environment used to test suspicious programs that may contain viruses or other malware, without allowing the software to harm the host devices
• Data Sanitation AKA Content Disarm and Reconstruct (CDR): sandboxes all downloaded files, parses all executable code and reconstructs the files without any non-approved executable code. This eliminates malicious executable downloads.

The SDP Controller

It configures a Transport Layer Security (TLS) connection between the SDP Client and the SDP Gateway. This encrypted tunnel performs two functions

• It acts as a trusted channel between the client and the back-end resource by tying into your cloud solutions to authenticate (Public Key Infrastructure (PKI), Open ID, SAML, Active Directory …) and checks the authorization for any connection request.
• It carries a Certification Authority (CA) that sets up an encrypted tunnel between the client and the remote resource.

The SDP Gateway

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 :

• Confidentiality via encrypted tunnels
• DOS protection using TLS anti-DOS tokens in the SDP protocol
• Geo-location protection
• Segmentation eliminating lateral movement
• Information obfuscation
• Incident Response
• Quarantine