Zero Trust is about not trusting anything implicitly be it the user, device, application as well as your ‘network’, which historically has been considered private and protected. With this context, relying on Virtual Private Networks (VPNs), one-time authentication or device verification, network based access controls etc is not only not enough, it creates a security challenge with broad access ramifications, should the VPNs or one-time authentication efforts be compromised. The authorization of access has to be dynamic as well as continuous and access enforcement has to be granular to ensure appropriate restrictions are applied as security posture changes.
Old Approach | What Is Needed Today (aka Zero Trust) |
---|---|
Broad Network Access via VPN Gateways | Granular Controls |
User Authentication Only | Dynamic Context Based Authentication |
Static, Complex, Access Control Lists | Human-Readable, Automated Policy |
Disconnected Security Tools | Integrated w your Enterprise Tools |
Now that we have identified the characteristics of what is needed today, let us break the access problem down into core components to see how to create a continuous Zero Trust security paradigm.
There are 3 core elements when considering secure access. The accessing ‘Entity’, the ‘Channel’ utilized for access and finally the ‘Application or Data’ being accessed. Each of these three elements needs to be better understood to enable true Secure Access.
Entity
The Entity comprises at a minimum of users and often devices as part of the entity component. You have User Identity to authenticate the user, then followed by Device Trust often delivered through things like MAC address verification for example. In addition to this network centric solutions like VPNs deploy a VPN Client on end devices to validate user and device elements. While these are okay for static verification, users are often mobile, or using different devices like laptops, mobile phones etc. The context of all these along with usage patterns need to be incorporated to move from a static one-time authentication to context-aware authentication. Essentially a per access ‘score’ needs to be created to define the entity trying to access resources at that point in time. A VPN only approach completely misses the context as it only relies on one-time authentication before allowing broad access and lateral movement to all ‘private’ assets.
Old Approach | What Is Needed Today (aka Zero Trust) |
---|---|
Network-based Identity | Context-aware Identity |
One-time Authentication | Continuous Authentication |
Depending on a combination of factors, an entity’s access can be established at that particular instance and if those factors change, then the access provided to the entity changes. To keep track of this and to establish a variable access construct, entity access credentials need to be ‘calculated’ at that point in time. This will create the right ‘trust’ level for the entity at that moment. This introduces the first principle of secure access :- Quantified Trust.
1) QUANTIFIED TRUST
A combination of factors like user ID, device ID, location, etc., to determine a score utilized to establish trust and quantify a security posture. It is a context-aware access. It is no longer just about a one-time authentication, IP Address or long-lived certificates that grant access, but rather a range of factors combined to establish a contextual definition of the entity.
Channel
Now let us examine the second component in the Secure Access ecosystem, the ‘Channel’. Once an identity is established, a secure channel needs to be created to ensure that communication is private. Historically, a physical private network was used, which paved the way to a Virtual Private Network (VPN), which meant connecting to a ‘Central office’ and then accessing your data set via the VPN. Once you were on this ‘Private’ network, you are treated as having the same privileges as if you were within a ‘walled’ environment. You had full access to resources and could move laterally within this network. While the ‘channel’ was encrypted and secure, it allowed for broad access once you passed the one-time authentication phase. Often the setup was designed for long term access. Credentials, tokens and certificate used to enable this secure channel were managed by 3rd party tools/services, often requiring complex key management infrastructure that necessitate that these certificates have a fairly long shelf life. This by its very nature meant that if the authentication was compromised, this secure channel was exposed on a long term basis. The net result of this secure channel setup create problems like:
Security Gap: Large attack surface due to long lived tokens and certs with protection through one-time authentication leading to a weak security posture Scalability and Performance: Bad end-user experience due to slow performance as a result of multiple hops Complexity: Managing IP addresses, VPCs, VLANs and other network-layer attributes, creating complexities across all these factors.
Old Approach | What Is Needed Today (aka Zero Trust) |
---|---|
Broad Access | Granular Access |
One-time Authorization | Continuous Authorization |
Complex network controls | Simple Centralized Policy Engine |
The reliance on a ‘Gateway’ approach to creating a secure channel needs to be changed in favor of direct connections and continuous authorization where as the access posture of the entity changes so does the authorization. Continuous authorization results in ensuring that there is a small attack surface that is being continuously validated with a centralized policy engine to ensure the access is secure and more importantly not being exploited.
2) CONTINUOUS AUTHORIZATION
The notion of broad access based on tokens and or certificates that are long lived, leaves open a large attack surface. Authorization has to be continuously verified with a centralized policy engine and tokens/certs have a very short life as a result enabling a truly secure communication channel
Application/Data
The final piece in the secure access ecosystem is access enforcement to application/data. As enterprises have started to experience more challenges with a dynamic user base and a distributed application environment with hybrid and multi-cloud deployments, a move away from a centralized gateway VPN is the natural progression. Recently there has been an emergence of a centralized cloud service or a “man in the middle” cloud gateway service. While there is no hardware dependency in the cloud approach, traffic is routed through a centralized system, becoming the new choke point. Additionally the access enforcement is very coarse grained much the same way a gateway VPN approach. Besides the centralized choke point issue, there are security concerns especially when it comes to compliance related notions like GDPR which require data locality and ownership as compliance elements, which these services cannot address as the hosted environment of these services is often not in the local country.
Centralized approaches are not aligned with the scaled distributed nature of today’s enterprise environments. And with the increased breaches, enterprises need to own their data and their data plane so they have control of their security posture.
Old Approach | What Is Needed Today (aka Zero Trust) |
---|---|
Big bulky gateways | Distributed Proxies |
Public Data Plane | Own your data plane |
Given that the access paradigm needs to be dynamic, so should the enforcement. This means that access enforcement has to be very granular and allow a distributed proxy approach that enforces at a per application instance level at a minimum. This would enable an enforcement mechanism that is fine grained and targeted to each entity’s access profile and would adjust as profile changes were detected. A distributed access enforcement proxy mesh that has intelligence about each instance and coordinates with the policy engine and understands the identity at the point of access is the only approach that matches the dynamic user base with a distributed application environment. The result is that your data plane stays yours, and traffic does not need to be routed to a centralized cloud service where you give up control of your data plane.
3) DISTRIBUTED ENFORCEMENT
Finally broad access gateways like on premises VPNs or Proxy Clouds are all single points of failure and most cases offer all or nothing access. With a simple distributed mesh architecture, enforcement can be defined down to individual resources within the application.
All three of these elements: identity, channel, and enforcement must be coordinated to ensure that access is secure at all times. These three elements form the foundation of Banyan’s Continuous Zero Trust Platform. The Banyan TrustScore delivers on Quantified Trust, the Cloud Command Center provides a Policy Engine that delivers continuous authorization with ephemeral certificates and tokens, and the Distributed Access Tier offers the distributed enforcement needed for the hybrid and multi-cloud environments for any secure access use case.
In subsequent posts, we’ll write about specific real-world scenarios. For now you can register for a demo here and learn more about the platform.
You can also visit https://banyansecurity.io to schedule a demo and register for a free trial.