Accomplishing Zero Trust Security using SDP

 

The network perimeter use to be a well defined demarcation between what we considered trusted and untrusted networks. A firewall typically sat at the edge of network to block or allow traffic based on static policies. Inside users are typically given a greater level of trust to critical resources because it was assumed they could be trusted. 

But business migration to the cloud, APT threats and the mobile workforce has made the perimeter more fluid than ever.  And just as our threats and networks have evolved, so must our defensive models. Zero trust Security is an architecture for todays networks. And new technologies like the Software Defined Permiter have finally brought the concept to reality. 

 

Zero Trust Security

 

“Zero Trust” is a security model in which we throw out the idea of trusting anyone or anything based on where they sit in the network. Instead, every single connection attempt is verified before being a connection is established. Until trust can be established, resources are completely hidden from the network – leaving unauthorized users and devices segmented from even seeing anything else network. 

Verification involves a human and machine element before trust can be established. The human element involves verifying the user is who they say they are through authentication, and that they have permission to the resource they are requesting – through authorization. 

While this verifies the person, we also need to know that they are coming from a trusted device that has not been compromised, and that’s where the machine verification comes in. By verifying the machine or device a users is connecting on, we limit the exposure a compromised machine could have to sensitive data and prevent lateral movements across the networks. 

Once trust has been established through the verification process, we now have access to the requested resource and nothing else. Because zero trust security is built around the concept of need to know, I would only have access to the resources that I need and nothing else until that new request goes through the same process. 

In a Zero Trust security model the network is an constant, dynamic state of verifying users and devices. This means that if a verified users is compromised, the machine verification would fail and their access to the resource would be immediately cut off. An untrusted device is completely shut off from the rest of the network to prevent data exfiltration and lateral movement. 

Because zero trust security is just a model, there’s many products and technologies that can help us get there. a relatively new technology known as the “Software Defined Perimeter”, or SDP,  helps cary out many of the zero trust principals on your network. 

 

Software Defined Perimeter (SDP)

 

SDP borrows ideas from SDN in building out a “Zero Trust Network” and there’s three main components you need to know: the SDP client, the SDP controller and the SDP gateway. 

The SDP client is usually software installed on the endpoint which handles the wide range of functions, including device verification and tunnel setup. The device verification usually includes UBA or EDR features that monitors the endpoint for various behaviours that could indicate a compromised machine. Some examples can be like registry changes, unusual network traffic and IoC indicators . 

The SDP controller functions as a trust broker between the client and the backend resource. The controller ties into your IdM solution to authenticate and check authorization for the given request. The authentication could come in the form of PKI, OpenID, SAML and many other forms. The controller also carries a CA which sets up an encrypted tunnel between the client to the remote resource. The key thing here is that the controller only provides access for the specific resource the client is requesting and has authorization for. 

The third component of SDP is the gateway, which grants access to previously private resources. This is the termination point for the TLS connection from the Client . Once the gateway confirms with the controllers that the client can access the given resource, the connection to the application is allowed. 

The main difference between an SDP connection and, say, a NAC solution – is that NAC usually stops at layer 2. The SDP controller and gateway are operating at layers 2-7. This means that a user can authorized to access Application A on server 1, but not Application B or C. In SDP, an unauthorized user wouldn’t even be able to see that there are any other applications running on that server without being authorized. By comparison, an authorized user in a NAC design can see anything else on the network – which doesn’t prevent lateral movement. 

 

SDP in Action

 

So let’s put it all together and simulate how SDP works . In our example, a user with an SDP client running on their machine clicks on an application on their desktop. This sends out whats called a “Single Packet Authorization” (SPA). The SPA packet includes an encrypted key which the SDP controller can use to identify and authenticate who the user is. An encrypted tunnel is established between the user and the SDP controller using PKI, which the controller then uses for authentication, authorization and device integrity. The controller then sends the IP information of the SDP client to the SDP gateways. This allows the gateways to know ahead of time that it should expect a connection from the SDP client. From there, the SDP client initiates a TLS tunnel to the SDP gateway which then allows the client to run the application through the tunnel.  

 

Now all the while, SDP clients and gateway are communicating to the SDP controller and exchanging information. If a client’s key is compromised or invalid, it’s connection is blocked and all visibility to application or servers in the network is cut off. If a machine is showing signs of being compromised, it would no longer be consider trusted and also Cust off from access to the resources. (protocol) 

 

Final Thoughts

 

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 a TLS anti-DoS token in the SDP protocol
• Location protection
• Lateral movement
• Information obfuscation 
• Incident response
• Segmentation and quarantining 

In security, we’re always looking to disrupt the kill chain of an attacker by implementing multiple layers of security. If you saw my last video, titled “Breaking the kill chain” – you’ll immediately notice that the Zero Trust and SDP model can severely disrupt an attack at multiple layers of the kill chain. 

Zero trust does not reveal any information about the network or its resources without first going through the verification process, which limits the information an attacker can grab during the reconnaissance phase. 

The dynamic nature of constantly verifying the machine using the SDP client can detect unusual  activity during the ‘Installation’ and ‘Command and Control’ phase. And of course, the “need to know” principals applied through the zero trust models limits what an attacker can do during the ‘Actions on Objective’ phase.