Enabling a Zero Trust Architecture in Heterogeneous Environments

by John Walsh, chief strategy and technology officer, BlackRidge Technology


During the past several months our team has gone through an accelerated learning curve as we have been collaborating with industry leaders exploring methodologies on how to achieve the objectives of zero trust through the integration of assets in a heterogeneous environment.

 Zero trust can be thought of as a cyber security strategy or an approach to integrate network assets and services such as sensors or analytics and tools to constantly authenticate, authorize, monitor, and adaptively enforce policy and rules during every connection request and session within a heterogeneous perimeter-less shared network environment. Zero trust assumes a “‘never trust and always verify” stance to provide a consistent security strategy for users or devices accessing resources and data that reside anywhere, from anywhere in any way, with continuous authorization, visibility and analytics. This approach no longer relies on the trusted perimeter; in fact, the perimeter no longer exists, and there is no longer an inside or outside. 

A zero trust architecture (ZTA) is an organizing framework for implementing the zero trust model that must operate seamlessly on shared networks, compute infrastructures, and a heterogenous set of OEM applications with little to no horizontal integration services. This blog summarizes our work to integrate and verify a zero trust architecture using a heterogenous set of OEM applications, products, services, and topologies (i.e. legacy hardware infrastructure, VNF, SDN, SDC, including cloud based SaaS). The “house of zero trust’” illustrated below, is built on a foundation that is all about protecting the data flow and rights management using information and attributes provided by the six pillars to achieve the zero trust objectives and for the house to stand.For more information the “six pillars of zero trust” please see “Zero Trust Cybersecurity, Current Trends”, April 18, 2019 by the ACT-IAC.

zero trust architecture

Figure 1 - House of Zero Trust

OEM applications (i.e. sensors, analytics, tools...) typically play in one or more of the verticals (pillars) providing zero trust components and information attributes that are required to achieve zero trust. Many of these applications are in place in typical network architecture implementations. To achieve true zero trust, the challenge is in integrating these to leverage all the information and attributes that they provide to enable the zero trust model. Furthermore, the method for aggregation and integration for accomplishing this must be capable of operating securely and seamlessly across shared heterogeneous legacy and software defined network environments.

In our efforts over the last several months, we collaborated with industry to validate an agnostic methodology to aggregate information for establishing: composite identity; a confidence level based on attributes associated to the identity; the enforcement of least privilege access rules and policies based on confidence level; the ability to continuously monitor and adaptively respond to post session establishment behaviors; and do so for every connection request or session in a perimeter-less topology independent environment. There are many challenges in integrating horizontally to achieve zero trust objectives in a heterogeneous environment. Many of the OEMs applications (i.e. sensing methods, algorithms, and protocols) are proprietary and do not share. Establishing a horizontal method for integrating the capabilities available within the architecture to establish this is a critical enabler for achieving zero trust. Especially in leveraging the investment made in existing infrastructures and environments.

ZTA Demonstration Environment and Objectives

Many thanks to our industry partners and B&D Consulting for their collaboration and support in establishing a common test bed platform and architecture for ZTA development and assessment. In doing so, we collectively demonstrated secure ZTA reference architecture and feature functionality and capabilities in a heterogeneous OEM application, services, and topology environment. Some of these objectives included:

  • Providing multiple options for achieving reference architecture zero trust objectives.
  • Integrate with multiple OEM applications/tools and services in a heterogeneous environment.   
  • Use multi-component identity, Confidence Level, and enforce rules and policy as the horizontal integration protocol and do so for each TCP/IP session (pre and post session request).
  • Demonstrate enhanced session-based monitoring, detection, analytics, and dynamic confidence level for adaptive response.
  • Operate in a topology independent environment including SDC, SDN/VNF, VDI, and Cloud Services environments
  • Operate agnostically with multiple policy and rule engines, SIEMs, Analytics et. al.
  • Develop options and ability to overcome ZTA deployment constraints in targeted environments and deployments

Over a period of several months we worked concurrently to develop and demonstrate a ZTA network capability with the flexibility of integrating information from various OEM applications and services. We accomplished this by aggregating certain information and attributes to establish composite identity (from the devices, applications, multiple-factor authentication, and others) using information and attributes provided from applications or services working with industry leaders such as Cisco, Forescout, Centrify, Splunk, Palo Alto Networks, Dtex Systems, MS Active Directory, and others. Based on the availability of specific information and attributes associated with the composite identity, a confidence level was derived to which specific least privilege rules and policies were associated. Work-flow included the detection of a device or request pre-session as part of the process to determine compliance prior to connecting and generating a session identity. This pre-session process can use information from the work-flow prior to enabling the device to connect to the network to establish its’ identity and confidence level (i.e. geo-location, past history, credentials, port access, and so on). Once this identity and confidence level were established, the TCP/IP request was authenticated and authorized (or denied) at the destination while network session activities are continuous monitored. In this way for example, using Splunk to monitor denied packets (session authentication or authorization requests) provides an indication of either unauthorized presence or requests. Once a certain threshold is reached, the confidence level associated with specific identities being denied are changed and a corresponding policy or rule is enforced (i.e. re-direct, quarantine, or drop). In a similar way other sensors or analytics such as monitoring data flow and rights management can enforce based on parameters being observed, risk threshold criteria reached, and adaptively change confidence level to enforce associated policy and rules dynamically.

Zero Trust Lab demon

Figure 2 - Zero Trust Architecture Lab Demonstration Environment

Note that for the lab demonstration architecture the management plane was not isolated.


During the last several months we have successfully demonstrated a methodology for integrating heterogeneous applications, services, and topologies in architectures pivoting to provide zero trust model features and capabilities. As part of this process we are benchmarking this reference architecture against U.S. Government zero trust and public announcements to maximize synchronization. In accomplishing this, we enable the ability for organizations to assess their existing environment and provide a path that leverages their existing investment while substantially enhancing their security posture.

This collaborative effort resulted in several significant discoveries and accelerated learning. Some key take-aways among others:

  • Most networks have components of what is required to move towards the zero trust model but lack the capability to integrate as described.
    • Many solutions claim “zero trust” but they are only components; Need a horizontal component to securely “glue things together”
    • In many respects, degrees of zero trust can be achieved by “re-packaging and integrating” existing assets
  • The Six Pillars (verticals) of Zero Trust are multiple layers that need to be integrated (horizontal) in a heterogeneous environment:
    • Legacy topology and applications
    • Must be SDC, Cloud, SDN/VNF compatibility, heterogeneous environment (including legacy)
    • Integrating the OEM technologies, applications, tools, and services in this manner provides comprehensive zero trust capabilities that substantially enhance the security posture using existing capabilities to redefine the landscape and countermeasure many of security vulnerabilities and challenges
  • Requires a “Collector” to aggregate certain information and attributes acting as an interface with the OEM applications or services providing input for Composite Identity, Dynamic Confidence Level, Continuous Monitoring and Enforcement... and a common, seamless method for transport.
  • The structure or approach to establishing policy and rules in a heterogeneous environment is important in many respects that drive the degree of complexity and success. There is certainly a roadmap required to determine what elements are critical in maintaining the integrity of specific assets and data for the business or mission to determine what zero trust characteristics are critical, what connections (i.e. work-flow) need to be made, the policies and rules and how to implement and enforce them to achieve the objectives.
    • In our demonstration for example, OEM applications or services could only downgrade confidence post session (i.e. after TCP/IP session authentication and authorization) based on specific parameters risk threshold updates based upon criteria and analytics from applications/services monitoring things like data flow and rights management, denied session establishment, behavior, and others. In this model, to re-establish confidence would require administrative or other analytics intervention to restore the identities ability to establish its next session request confidence level.  Longer term could automate with latching and autonomous algorithms
  • Premise – zero trust model is a perimeter-less shared network heterogeneous environment.This has many implications that must be considered to run seamlessly within the legacy and future greenfield and software defined environments... must operate across traditional and next generation boundaries seamlessly also requiring destination based policies and rules enforcement at the single TCP/IP session level for granular segmentation and segregation over origin based group policies.
  • Zero trust model is comprehensive and challenging