Software-Defined Access: Remote Access integrations

If you’ve embarked on the journey to enterprise LAN micro segmentation nirvana with Cisco Software Defined Access (SDA), we applaud you. You’ll be well on your way to enhanced security maturity level assessments, better automation and visibility and a much cleaner and simplified architecture in general.

Until you get to the realisation that remote users who need to access resources and platforms within the corporate LAN or Data Centre environments, don’t have that same security construct for end-to-end policy enforcement. Traditionally, Remote Access VPN’s connect into a defined security zone and firewall rules need to exist on there to allocate access to resources on the internal network. Fundamentally, this architecture connects to an SDA fabric as a “macro-segmentation” point where the LAN fabric is segmented from the remote access security zone by firewall.

But this is where Cisco Secure Access (CSA) plays a role. If you are either fully running an SDA fabric campus network, considering it, or in the middle of transitioning to it, you really need to be considering CSA for remote access as it forms part of the Cisco end-to-end policy enforcement capability called “Common Policy”.

By integrating your Cisco Identity Services Engine (ISE) into Cisco CSA, all the Security Group Tags (SGT) you use to define your fabric micro-segmentation groups, are readily available to use in your remote access rules. So you can apply your Bio-medical tag to bio-med users and this will apply the same consistent SGT rule enforcements for traffic entering via the Cisco Secure Access remote access path.

Think about that for a minute and let it sink in.

Historically, remote access users need rules in the firewalls based on network segments (most often IP subnets) they need to connect to. That involves either complex user profiles and / or considerable firewall rules and zone-based policies.

When leveraging Cisco Secure Access for your remote user access, you leverage the same Identity policies you’ve already created for your SDA fabric and apply them to users connecting remotely. So as they connect in to the network via the CSA service, they are applied the appropriate Security Group Tags and these are adhered to via the macro-segmentation firewalls AND the internal micro-segmentation rules needed to control access to the required internal resources.

Furthermore, CSA does this identity piece utilising a Zero Trust framework where users are connected, identified and continually validated from a security trust perspective. Traditional remote access VPN’s do not implement a “never trust, continually verify” model and are incapable of this. RAVPN’s will authenticate a user and once validated, will continue to have “trusted” status for the duration of the connection. ZTNA introduces the continual validation status evaluation to the equation which results in an enhanced security posture for companies protecting their assets from remote users.

Summary

Traditional remote access virtual private network (RAVPN) connectivity models are being decommissioned now and replaced with Zero Trust Network Access (ZTNA) platforms to increase security postures through a continual trust validation process. RAVPN’s are also being phased out by security vendors due to the complexity associated with continual patching and upkeep of Secure Socket Layer (SSL) protocol vulnerabilities that are a target for exploitation from threat actors.

Whilst there are many Secure Services Edge (SSE) providers out there in market now providing full ZTNA secure connectivity options, Cisco’s Secure Access platform should be at the top of the list for any enterprise network that is looking to migrate away from their legacy RAVPN services to a modern day SSE solution. Particularly if they are looking to implement Cisco Software Defined Access (SDA) across their enterprise campus. The inherent integration of Security Group Tags across both SDA and CSA will allow you to implement end-to-end segmentation policies you cannot easily achieve with a multi-vendor approach. This is Cisco’s key differentiator here and network and security teams will greatly benefit from this architecture when implemented together.