Issue 1

Zero Trust Architecture and Solutions

2

In the era of cloud computing and big data, the network security perimeter is gradually disintegrating, and internal and external threats are intensifying, leading to the failure of the traditional perimeter-based security architecture, therefore the zero trust security architecture comes into being. The zero trust security architecture establishes a dynamic digital identity-based perimeter with four key capabilities, which are identity-based schema, resource secure access, continuous trust evaluation and adaptive access control. It helps enterprises realize a new generation network security architecture with comprehensive identity, dynamic authorization, risk measurement, and management automation.

This paper begins with the background, definition and development history of zero trust security, then proposes a general zero trust reference framework, and takes Qi An Xin Zero Trust Security Solution as an example to interpret the application scheme of zero trust reference framework, finally discusses the zero trust migration methodology, and puts forward the migration ideas with defining the vision, planning first and constructing step by step.

1. IntroductionThe enterprise network infrastructure is becoming more and more complex with gradually blurred perimeter. The digital transformation has driven the rapid evolution of information technology, new IT technologies such as cloud computing, big data, Internet of Things and mobile internet have brought new productivity to all industries, in the meantime, they also have brought great complexity to the enterprise network infrastructure. On one hand, the adoption of cloud computing, mobile internet and other technologies makes enterprise’s staff, businesses and data go outside of the enterprise’s digital walls; on the other hand, the open and collaborative demands for new technologies, such as big data and Internet of Things, lead the outside staff, platforms and services pass through the digital walls and go into the enterprises. The modern enterprise network infrastructure has no single, well-recognized and clear security perimeter anymore, in other words, enterprise security perimeter is gradually disintegrating, and the traditional perimeter-based network security architecture and solutions are found difficult to adapt to modern enterprise network infrastructure.

Zero Trust Architecture and Solutions

Zero Trust Architecture and Solutions 2 Research from Gartner Market Guide for Zero Trust Network Access 14 About Qi An Xin Group 21

Zero Trust Architecture and Solutions is published by Qi An Xin Group. Editorial supplied by Qi An Xin Group is independent of Gartner analysis. All Gartner research is © 2020 by Gartner, Inc. All rights reserved. All Gartner materials are used with Gartner’s permission. The use or publication of Gartner research does not indicate Gartner’s endorsement of Qi An Xin Group’s products and/or strategies. Reproduction or distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company, and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner research, see “Guiding Principles on Independence and Objectivity” on its website.

3

3

In addition, the network security situation is not optimistic. External attacks and internal threats are intensifying, organized attacks, weaponized attacks, and advanced attacks with data and services as targets can still easily find loopholes that break through the perimeter of the enterprise, while internal threats such as unauthorized access to internal businesses, employee mistakes and intentional data theft have been popping out. Faced with such severe security challenges, the industry’s security awareness has been paid more attention, and the security investment becomes also higher. However, the security effect is not that satisfactory, and security incidents emerge one after another. What is the root cause of the failure for the traditional security architecture? The fundamental basis of security is to deal with risks, and the risks are closely related to “loopholes”. What “loopholes” lead to the failure of traditional security architecture? The answer is trust. The traditional perimeter-based network security architecture assumes that the people and devices in the internal network are trustworthy, therefore the security strategy is to build the digital walls of the enterprise, and the security products such as firewalls, WAF, IPS are sufficient to protect the perimeter of the enterprise network. However, one should assume that there are always undiscovered loopholes in the network systems, there are always discovered but unpatched loopholes in the systems, the systems have always been infiltrated and that the insiders are always unreliable. These four “always” assumptions overturn the technical methods of traditional network security by segmenting network and building the walls, and overturn the abuse of “trust” under the perimeter security architecture, which the perimeter-based security architecture and solutions have been found difficult to deal with today’s network threats.

A new network security architecture is needed to cope with the modern and complex enterprise network infrastructure, and to cope with the increasingly severe network threat situation. Zero Trust Architecture emerges in this context and is an inevitable evolution of security thinking and security architecture.

1.1. Definition of Zero Trust

Zero Trust Architecture has been developing rapidly and been gradually mature, while different versions of the definition are described in different dimensions. In the book Zero Trust Networks: Building Secure Systems in Untrusted Networks, Evan Gilman and Doug Barth definite that a zero trust is built upon five fundamental assertions:1

• The network is always assumed to be hostile.

• External and internal threats exist on the network at all times.

• Network locality is not sufficient for deciding trust in a network.

• Every device, user, and network flow is authenticated and authorized.

• Policies must be dynamic and calculated from as many sources of data as possible.

In short, no person/device/application in the enterprise network should be trusted by default, no matter it is in the internal or external network. The fundamental basis of the trust should be based on the refactored access control using right authentication and authorization. Zero Trust Architecture has paradigmically changed traditional access control mechanism, and its essence is adaptive trusted access control based on identity.

In the recently published “Zero Trust Architecture (NIST.SP.800-207-draft)”, NIST points out that “Zero Trust Architecture is an end-to-end approach to network/data security that encompasses identity, credentials, access management, operations, endpoints, hosting environments, and the interconnecting infrastructure”. It considers zero trust as an architectural approach to data protection, while traditional security solutions focus only on perimeter defense with too much access open to authorized users. The primary goal of zero trust is

to perform fine-grained access control based on identity in order to cope with the increasingly severe risk of overpowered lateral movement.

Therefore, NIST defines Zero Trust Architecture as follows:

Zero Trust Architecture (ZTA) provides a collection of concepts, ideas, and component relationships (architectures) designed to eliminate the uncertainty in enforcing accurate access decisions in information systems and services.2 This definition identifies key issues that zero trust needs to address: eliminating unauthorized access to data and services, underscoring the importance of fine-grained access control.

1.2. History of Zero Trust

Analyzing the development history of zero trust, it is not difficult to find that the different perspectives of zero trust finally show strong consistency after developing and merging.

The earliest prototype of zero trust came from Jericho Forum, founded in 2004, whose mission was to define cyber security under de-perimeterization trends and to find solutions. The actual term “zero trust” was officially coined in 2010, indicating that all network traffic is untrusted by default, and all access requests for all resources need to be securely controlled. In the beginning, zero trust came up with a solution that focuses on fine-grained access control over the network through micro-segmentation to limit the attacker’s lateral movement.

With the continuous evolution of zero trust, identity-based architecture has gradually gained mainstream acceptance in the industry. The transformation of this architecture is closely related to the adoption of mobile computing and cloud computing. In 2014, Google has published several papers on how to build Zero Trust Architecture for its employees internally, based on its own project BeyondCorp. BeyondCorp’ s starting point is that it is no longer enough to build

1 Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks (O’Reilly Media, 2017)2 NIST, Zero Trust Architecture, 2019.09, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207-draft.pdf

4

security controls just for corporate perimeter, requiring access control to be moved from the perimeter to each user and device. By using Zero Trust Architecture, Google has successfully abandoned the adoption of traditional VPNs and ensured that all users from insecure networks have secure access to the enterprise business through a new architecture.3

With the continuous improvement of zero trust theory and practice of the industry, zero trust has gone beyond the scope of the original micro-segmentation in network layer, evolved into a new generation of security solutions based on identity, which can cover many scenarios, such as cloud environment, big data centers and micro-services. Research organizations are also ready to optimize their security architectures and systems.

By analyzing various definitions and frameworks of zero trust, it can be seen that the essence of Zero Trust Architecture is adaptive identity-based access control, the security capability of focusing on identity, trust, resource access and adaptive access control, and the multi-dimensional factors such as people, process, environment and access context based on business scenarios, and continuous assessment and evaluation of the zero trust is needed. The adaptive adjustment of authority by trust levels can help form a dynamic adaptive security closed loop with strong risk coping ability.

2. Zero Trust Reference FrameworkThe key capabilities of zero trust security can be summarized as follows: identity-based schema, resource secure access, continuous trust evaluation and adaptive access control. These capabilities map to a set of interacting core architectural components that are highly adaptable to various business scenarios.

2.1. Key Capability Model

The essence of zero trust is to establish an adaptive identity-based access control system between the access subject and the access object. Through the key capabilities of identity-based schema, resource

secure access, continuous trust evaluation and adaptive access control, it encrypts, authenticates and enforces all untrusted access requests, based on the digital identity of all participating entities of the network, aggregates a variety of data sources for continuous trust evaluation, and adjust the permissions dynamically according to the trust levels, and eventually establish an adaptive trust relation between the access subject and the access object.

In Zero Trust Architecture, the access object is the core protected resource, which should be protected by the protection surface, including the enterprise’s business applications, service APIs, operations, and asset data, and etc. The access subject includes digital entities such as people, devices, applications, and systems, all of which can be identified. In certain access contexts, those entities can also be combined to further clear and define the subject.

Key capabilities of Zero Trust Architecture include: identity-based schema, resource secure access, continuous trust evaluation and adaptive access control. (See Figure 1 for a conceptual model.)

1) Identity-based Schema

In order to construct access control system based on identity rather than network location, it is necessary to give digital identity

to the people and device in the network, and combine the identified people and device at run-time to set up access subjects, and set up the least privilege for the access subject.

Digital identity is the cornerstone of Zero Trust Architecture and it needs to realize “comprehensive identity “. It is not enough to simply create identities for people and/or devices, and all entities involved in network interactions. In fact, in the age of Internet of Things, things have become important participating entities, whose cardinal number has gone far beyond people.

In Zero Trust Architecture, based on different access contexts, the access subject can be a dynamic combination of numeric digital entities, such as people, devices and applications, which is called “network agent” in the book Zero Trust Network. It is the term given to the combination of data known about the actors in a network request, typically containing a user, application, and device, which are the inextricable context of an access request. It is generated on-demand when authorization decision is made and thus it is usually of short time. Access agent’s constituent elements (users or devices) information are generally stored in the database for real-time query and combination when authorized, so the network agent represents the real-time state of the attributes of users and devices in each dimension at the time of authorization.4

3 Google, https://cloud.google.com/beyondcorp/ 4 Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks, Aug., 2019

Source Qi An Xin Group, 2019

Figure 1 Key Capabilities of Zero Trust Architecture

5

5

The principle of least privilege is one of the key practices that should be followed by any security architecture. However, Zero Trust Architecture advances the principle of least privilege, and follows the principle of dynamic least privilege. If users do need higher access rights, then they can and only get those privileges when they need them. On one hand, it emphasizes that the authorized subject is not a single entity, but a composite subject as network agent, not only follows the principle of least privilege by the user, as well as a principle followed by the device; on the other hand, the authorized subject can be further defined based on the subject attribute, environment attribute, trust level and the security level of the object. In contrast, traditional identity and access control related implementations generally authorize people and devices separately. Zero trust is a paradigm that uses network agents as the authorized subject. It generates temporary entities on demand at the time of authorization decision, which has strong dynamics and risk awareness, therefore it can greatly mitigate security threats such as credential loss and unauthorized access.

2) Resource Secure Access

Zero Trust Architecture focuses on the construction of the business protection surface to realize the protection of resources. In Zero Trust Architecture, applications, services, interfaces and data can be regarded as business resources. Setting up a protection surface to shrink the exposed surface, all business resources are required to be hidden by default, and all business access requests are subject to full traffic encryption and mandatory authorization according to the authorization results. The resource secure access mechanism needs to work at the application protocol layer as much as possible.

To build Zero Trust Architecture, it is necessary to pay attention to the core assets that need to be protected, sort out the various exposed surface of the core assets, and hide the exposed surface. Thus, the various access paths of the core assets are hidden behind the security components as not visible to the access subjects by default

except for obtaining the access requests that are authenticated, licensed, and trusted in compliance with the security policies. In addition to satisfying the principle of least privilege, it can also effectively alleviate security threats such as detection of core assets, denial of service, vulnerability utilization, illegal crawling, and etc.

Network eavesdropping and middleman attacks are the most common causes of data thefts. In the zero trust practice, it is necessary to encrypt the traffic of all applications and APIs calls with high-intensity TLS, and to consider the support of the domestic cipher algorithm. Zero trust emphasizes full-traffic encryption agent rather than just local traffic of authentication request, which also distinguishes the trusted agent in Zero Trust Architecture from traditional authentication gateway.

In order to prevent access control mechanisms from being bypassed, it is necessary to have a policy enforcement point. In Zero Trust Architecture, all access requests should be authenticated, licensed, and have considerable trust level. Zero Trust Architecture needs to adapt different business scenarios, identify the subject from different access protocols and methods, and relate the multi-level and multi-layer accesses to the subject. Only in this way, can it be effectively ensured the access control without loopholes.

3) Continuous Trust Evaluation

Continuous trust evaluation is a key method to build trust from scratch in Zero Trust Architecture. Through trust evaluation model, identity-based trust evaluation capability is realized. It also assesses the context environment of access and identifies the abnormal behavior of access request and adjusts the result of trust evaluation at the same time.

Entities in the physical world, such as people and devices, are identified as digital identities in the digital world, so trust evaluation of entities first requires a trust evaluation of them, which must cover at least two types of digital identities: people and devices. Identity-based trust evaluation systems need to be

established and cover all stages of the digital identity life cycle, including: the configuration of the digital identity, the trust evaluation of states and attributes, and the trust evaluation of the physical entity to digital identity mapping process (identity creation and verification). As mentioned above, the access subject is the network agent composed of the trinity of people, devices and applications, therefore, on the basis of the identity trust, it is necessary to evaluate the subject trust, which is the dynamic adjustment of the identity trust in the current access context, and related to authentication intensity, risk state and environmental factors. The identity trust is relatively stable. Like the network agent, subject trust is a kind of short-time dynamic trust, and adaptive access control based on subject trust levels is the essence of zero trust.

Trust and risk are closely associated with each other, even as the two sides of one coin. In Zero Trust Architecture, besides the trust evaluation, the influencing factors of environmental risk need to be considered, and all kinds of environmental risks need to be assessed and responded to. However, it is important to note that not all risks will affect the trust degree of the identity or the subject. For example, in the process of accessing a business resource, device camera may perceive that many people are surrounded observing, which is risky to sensitive resources and should be mitigated by revoking the current access sessions. Frankly, in most cases there is no need to degrade the current device and user’s trust levels, if this behavior constitutes an inherent pattern, the subject may be deemed to be intentional, and in other words, the subject’s trust should be degraded therein.

The demand of ability of behavior-based anomaly detection and trust evaluation requires establishing models and maker quantitative evaluation for the key factors affecting the trust including baseline deviation of the individual behavior of the subject (corresponding digital identity), baseline deviation of the subject and the group, aggressive behavior of the main environment, and risk behavior of the main environment. Comprehensive assessment

6

needs to integrate the behavioral analysis with identity situation to reduce misjudgment and reduce the negative impact on the user experience.

4) Adaptive Access Control

Adaptive access control is an important embodiment of the security closed loop capability of Zero Trust Architecture. It is suggested that flexible access control baselines should be implemented through the combination of RBAC and ABAC, hierarchical business access can be realized on the basis of trust level, at the same time, real-time intervention of access rights should be performed when risks exists in the context and environment of access, and assessed whether the trust of the access subject should be degraded.

The establishment of any access control system is inseparable from the access control model, and it is necessary to establish a permission baseline based on a certain access control model. There are many access models, including RBAC, ABAC, MAC, DAC, and other classical models and their variants. Zero trust emphasizes grayscale philosophy, there is no need to worry about which is better between RBAC and ABAC from the practical experience, but take the integration into consideration. It is suggested to implement coarse-grained authorization based on RBAC model, establish a baseline of authority to meet the enterprise’s basic principle of least privilege, and implement dynamic mapping and filtering mechanism based on subject, object and environmental attributes while giving full play to the dynamics and flexibility of ABAC. The permission baseline determines the full set of permissions allowed by a subject, and at different access times, the access context, trust level, and risk state may be closely related to the granted access rights.

Besides the access control baseline, the hierarchical access control strategy should be implemented according to the trust level of the subject and the security level of the object. When the trust level of the subject is higher than that of the object, access will be actually granted, otherwise denied to alleviate

the risk. According to the continuous trust evaluation, the trust level of the subject will be adjusted, dynamically within the baseline of access control in real time.

It should be noted that not all risks have an impact on trust, especially environmental risks, a corresponding disposal strategy should be implemented once the risk occurs. The common approach is to cancel the access session. Therefore, the control plane will be able to receive the risk notification of the external risk platform and process the current access session on demands, so as to realize the interaction of risk management, and truly integrate Zero Trust Architecture and other existing security solutions of the enterprise.

2.2. Basic Principles

The section “Key Capability Model” describes four zero trust key capabilities of “identity-based schema, resource secure access, continuous trust evaluation, and adaptive access control” in detail. These security capabilities need to be supported in Zero Trust Architecture through architectural components, interactive logic, and etc. In the process of mapping security capabilities into the architecture, some basic architectural principles would apply in order to ensure that the implemented architecture can effectively meet the security requirements under the new IT environment. The principles include:

• Principle of Comprehensive Identity

Far more than managing the identity of people, all access subjects should be identified, including people, devices, and etc. The subjects of access control are network agents, not isolated people or devices.

• Principle of Application-level Control

The access should work as much as possible in the application layer rather than the network layer, which is usually implemented by an application agent. The application agent should be full-flow and fully encrypted. It is not allowed to only authorize the agent to applications’ authentication request.

• Principle of Closed Loop Security

The trust level is evaluated based on the attributes, behaviors and access context of the subject, and the access authority is dynamically and automatically adjusted in real time based on the trust level to form an automatic closed loop security.

• Principle of Business Aggregation

Zero Trust Architecture is a built-in security. It is necessary to design the architecture based on the actual business scenarios and security conditions. It is recommended to plan the zero trust security and business simultaneously. Zero Trust Architecture should have strong adaptability and can be tailored or extended according to the requirements of actual scenarios.

• Principle of Multi-scenario Coverage

Modern IT environment has a variety of business access scenarios, including user access resources, service API calls, data center service interactions, and etc. Access terminals include mobile, desktops, as well as IoT devices. The deployment locations of business are also various. Zero Trust Architecture should cover various scenarios and maintain its strong scalability to achieve universal security capabilities for all business scenarios.

• Principle of Component High Interactivity

The components of Zero Trust Architecture should have high interactivity, and the components should be adjusted to each other to form a whole to mitigate all kinds of threats and to form a secure closed loop. In the practice of Zero Trust Architecture, one should not stack or piece together product components. The interactivity of each product is an important foundation for the implementation of zero trust.

2.3. Core Components

The core logical architectural components of Zero Trust Architecture are shown in Figure 2:

7

7

1) Trusted Proxy

A trusted proxy is a data plane component, the first gateway to resource secure access, and a policy execution point for adaptive access control capability.

After the trusted proxy intercepts the access request, the access subject is authenticated through the adaptive access control engine, and the authority of the access subject is dynamically determined. Only the access requests that pass the authentication and have access rights are released. At the same time, the trusted proxy should encrypt all access traffic, which also demands its high performance and high scalability. Supporting horizontal extension is the core capability that the trusted proxy must have.

According to different scenarios, the product forms of the trusted proxy are quite different. For example, for users accessing services, the trusted proxy may be the application gateway based on reverse proxy technology. For service interface calls, the trusted proxy may be an API gateway. For service mesh scenario, a trusted proxy can be simplified as an agent module running in the service environment. Similarly, capability requirements vary in different scenarios. Trusted proxy is required to support not only application-level reverse proxy, but

also TCP proxy technology for some legacy applications according to different service applications even in the same scenario where users access services. In the actual implementation of the scheme, trusted proxy with various forms must work under the unified management of the control plane components to ensure the implementation of the security strategy in various scenarios without differences.

2) Adaptive Access Control Engine

The adaptive access control engine is linked with the trusted proxy to authenticate and dynamically authorize all access requests, constituting the policy decision point of Zero Trust Architecture control plane.

The adaptive access control engine determines the authority of all access requests. The authority determination is based on context attributes, trust levels and security strategies dynamically rather than on static rules. It is based on identity repository, authority repository and trust repository, with the first providing the identity attributes of the access subject, the second providing the basic authority repository line, and the third continuously maintaining the control by the identity analysis engine through real-time multidimensional risk association and trust evaluation.

In order to implement the identity-based access control strategy and dynamic authority adjustment, the adaptive access control engine components should authenticate identities and manage sessions of the access subject simultaneously to ensure that all access requests are identity-aware, visible, and controllable.

3) Trust Evaluation Engine

As the core component to realize the capability of continuous trust evaluation in Zero Trust Architecture, the trust evaluation engine is linked with the adaptive access control engine to provide the trust level assessment as the basis of authorization decision.

It continuously receives the log reports of the trusted proxy and the adaptive access control engine, combines the data of the identity repository and the authority repository, carries out profiles on the identity and continuous analysis on the access behaviors, assesses continuously by using big data and AI technology, and finally generates and maintains the trust repository to provide the decision for the adaptive access control engine. In addition, the trust evaluation engine can also receive the analysis results from external security analysis platforms, including: trusted environment awareness, continuous threat detection, situation awareness and other security analysis platforms, which may well supplement the data required for identity analysis and enrich the context so as to carry out more accurate risk identification and trust evaluation.

4) Identity Security Infrastructure

The identity infrastructure is critical for building the identity-based capabilities of Zero Trust Architecture.

The identity infrastructure includes at least the functional components of identity management and authority management, the former may realize identity and identity life-cycle management of various entities while the latter may carry out fine-grained management and tracking analysis of authorization policies.

Source Qi An Xin Group, 2019

Figure 2 Architectural Components of Zero Trust Architecture

8

The identity security infrastructure of Zero Trust Architecture should meet the complex and efficient management requirements under the modern IT environment. The traditional static identity and authority management fails to meet the requirements of the new technological environment and cannot support the enterprise’s strategic visions of building the zero trust security architecture for not being agile and flexible enough or manage identity and authority management for more new scenes and applications. In addition, in order to improve the management efficiency, the key capabilities of modern identity management such as self-service and workflow engines are also essential.

With the present situation of the existing enterprise infrastructure, the identity security infrastructure can be handled flexibly in the

implementation of specific schemes. Any enterprise with a mature identity infrastructure to meet the requirements may couple Zero Trust Architecture with an existing system. Any enterprise does not have an identity infrastructure, or its maturity cannot meet the requirements of Zero Trust Architecture should build or optimize one.

2.4. Adaptability for Multi Scenarios

Under a modern IT environment, business scenarios are diverse. Those scenarios may be sorted out as: resource access scenario, data exchange scenario, and service mesh scenario according to their typical business architecture, access subjects and objects, and traffic modules. Zero trust reference framework should be applicable to each scenario and can combine multiple scenarios as needed to form a unified zero trust security architecture. (See Figure 3 for a conceptual model.)

The following presents the simplified schematic diagram of the zero trust reference framework for each business scenario respectively, this article leaves out the components of identity security infrastructure, other security analysis platforms and the differences there between.

1) Resource Access Scenario

Resource access refers to the scenario where users access business applications, and is also the main scenario of Zero Trust Architecture. There are many sub-scenarios in this one, such as desktop office scenario, mobile office scenario, dumb device access scenario, and etc. Types of users, devices and applications may vary according to different sub-scenarios, which put forward more capability requirements for the implementation of zero trust logic components. (See Figure 4 for a conceptual model.)

The person/user of the access subject may be an insider, an employee, an external partner, or even the customer of the enterprise. The device of the access subject may be a PC, a mobile device, an enterprise-owned device, or a BYOD device. In addition, application types, especially access means of applications, including WEB applications based on HTTP protocols, some well-known non-HTTP protocols, such as RDP, SSH, and even some non-well-known private protocols, may vary.

A mature zero trust solution should meet the business access requirements of different people and devices to various application protocols, and have high adaptability while maintaining the same architecture.

The above business access architecture diagram does not cover the fine-grained access control at the functional level or even the data level within the application. In terms of the specific implementation plan, it is suggested that Zero Trust Architecture and the business architecture are closely coupled. The components of the Zero Trust Architecture can transfer identity, trust, and authority information to the business application which can perform finer-grained access control based on this information. In this way, not only the zero trust can be

Source Qi An Xin Group, 2019

Source Qi An Xin Group, 2019

Figure 3 Different Business Scenarios

Figure 4 Resource Access Scenario

9

9

regarded as the endogenous capability of the business security, but also the development, deployment and continuous evolution of the security and business can be ensured independently to a certain extent.

2) Data Exchange Scenario

Data exchange refers to a business scenario in which external applications/platforms exchange data through service interfaces and enterprise services. In the era of big data, open collaboration has become the trend of information technology development, and the data exchange scenario has gradually become the mainstream. (See Figure 5 for a conceptual model.)

Zero trust solutions for data exchange scenario face the challenges of diverse interfaces and computing environments where access subjects run. Trust proxy which is compatible with various data exchange protocols or API interfaces is required. Trust evaluation engine should collect and evaluate data from the computing environment in which access subjects run. Meanwhile the

data exchange protocols should be analyzed to better identify abnormal access behaviors. The adaptive access control engine should perform fine-grained access control at the content level.

In addition, under the data exchange scenario, the access subject that directly conducts the data exchange with the trusted proxy is the external application, not the user or the device, which requires identifying and evaluating the user and the device that accesses the external application through certain technical means, so as to ensure end-to-end trust establishment and fine-grained access control of identity awareness.

3) Service Mesh Scenario

Service mesh refers to the multi-party interaction scenario among servers within the data center. With the large adoption of container layout and micro-service technology, the service mesh scenario is increasingly evolving into the mesh access control among the data center workloads. (See Figure 6 for a conceptual model.)

Generally, the zero trust scheme in the service mesh scenario does not use independent trusted proxy as data plane components, but disperses them, and takes over each other’s access requests and interacts with the control plane by deploying trusted proxy. Numerous nodes and the complex access control rules set higher standards for both adaptive access control engine and trust evaluation engine of the zero trust solutions for service mesh scenario.

The service mesh scenario is also the deepest embedded scenario in the service architecture. It needs to be built in combination with the service mesh or container orchestration technology. It is best to plan Zero Trust Architecture at the same time as the service platform is built to achieve a true built-in security.

3. Zero Trust Security Solution This section analyzes the specific practice of the zero trust reference framework by the example of Qi An Xin ‘s zero trust security solution. Qi An Xin has been paying great attention to Zero Trust Architecture. Qi An Xin Zero Trust Security Solution is designed based on the zero trust reference framework, making full use of the advanced technological achievements, and making optimization in combination with typical domestic business and security status quo. At present, it is strongly advanced and feasible as it has been verified by a large number of practices and widely recognized by large organizations and enterprises in China.

3.1. System of Core Products

Qi An Xin Zero Trust Security Solution includes: Qi An Xin TrustAccess Adaptive Access Control Platform, Qi An Xin TrustID Identity Platform, Qi An Xin ID Phone Token and other agent compositions, as shown in Figure 7. In Qi An Xin Zero Trust Security Solution, Adaptive Access Control Platform and Identity Platform are logically decoupled. If the customer’s existing identity security infrastructure meets the requirements of Zero Trust Architecture, it is not necessary to deploy the Identity Platform, and the cost of construction can be reduced be making use of the existing system.

Source Qi An Xin Group, 2019

Source Qi An Xin Group, 2019

Figure 5 Data Exchange Scenario

Figure 6 Service Mesh Scenario

10

1) Qi An Xin TrustAccess Adaptive Access Control Platform

Qi An Xin TrustAccess provides the core capability of adaptive trusted access control in Zero Trust Architecture to quickly set up Zero Trust Architecture for enterprises and realize the zero trust migration of enterprise data.

The main components of Qi An Xin TrustAccess include: Trusted Application Proxy (TAP), Trusted API Proxy (TIP), Trusted Access Console (TAC), Identity Analysis (IDA), Trusted Environment Sensor System (TESS) and Trusted Network Sensor System (TNSS).

• Trusted Application Proxy (TAP)

Trusted Application Proxy (TAP) is the product implementation of the trusted proxy in the resource access scenario in the zero trust reference framework.

Based on the requirements of enterprise application-level access control, it realizes the ability of layered secure access, one-stop application access, application single sign-on, and application auditing.

Source Qi An Xin Group, 2019

• Trusted API Proxy (TIP)

Trusted API Proxy (TIP) is the product implementation of the trusted proxy in the data exchange scenario in the zero trust reference framework.

Based on the security requirements of API service, it realizes the unified agent, access authentication, data encryption, security protection, application auditing and other capabilities of APIs.

• Trusted Access Console (TAC)

Trusted Access Console (TAC) is the product implementation of adaptive access control engine in the zero trust reference framework.

TAC provides TAP/TIP with self-adaptive authentication service, adaptive access control and centralized management capabilities. According to various business access scenarios of the enterprise, TAC implements the functions of self-adaptive authentication service, unified configuration management of access control policies, centralized management of WEB applications and API services, dynamic

authorization, risk aggregation correlation, application auditing, etc.

• Identity Analysis (IDA)

Identity Analysis (IDA) is the product implementation of the trust evaluation engine in the zero trust reference framework.

IDA carries out comprehensive risk correlation judgment based on identity and authority information, TAP/TIP/TAC access logs, attributes and risk assessment reported by trusted environment sensor, logs and events submitted by other external analysis platforms. It uses big data analysis and AI technology to build a trust evaluation model for continuous trust evaluation and to provide TAC with trust level as decision-making basis.

• Trusted Environment Sensor System (TESS)

Trusted Environment Sensor System (TESS), as an important data source of IDA, provides the device environment security status and environment awareness of various scenarios and the real-time reliability judgment basis for IDA.

Figure 7 Qi An Xin Zero Trust Security Solution

11

11

• Trusted Network Sensor System (TNSS)

Trusted Network Sensor System (TNSS), also as an important data source of IDA, provides the security status and environment awareness of the network environment and the real-time judgment basis of network reliability for IDA.

2) Qi An Xin TrustID Identity Platform

Qi An Xin TrustID Identity Platform is a product implementation of identity security infrastructure in the zero trust framework, and is a modern identity and authority management product.

Qi An Xin TrustID can provide enterprises with more advanced and flexible modern identity and authority management capabilities. When TrustAccess’s own basic identity and authority management capabilities or the enterprise’s existing identity infrastructure does not meet the enterprise’s management needs, the capabilities of identity and authority management can be improved by TrustID to meet the capability requirements of the zero trust architecture to identity security infrastructure. In addition to serving TrustAccess, TrustID can also provide identity and permission-based services for the enterprise’s business systems and other scenarios that require identity, authentication, and authorization.

Qi An Xin TrustID also supports docking with the existing external identity source systems of the enterprise, including PKI, 4A, AD, etc. A healthy identity life cycle management capabilities is formed to provide identity infrastructure services for TrustID by integrating and synchronizing the existing identity sources of the enterprise.

3) Relation between Qi An Xin Zero Trust Security Solution and Reference Framework

Qi An Xin Zero Trust Security Solution splits and extends the product components based on the zero trust reference framework, but remains highly consistent on the overall architecture. Its product components are mapped to the zero trust reference framework as shown in Figure 8.

In addition, Qi An Xin Zero Trust Security Solution can seamlessly interacts with other Qi An Xin’s security products and solutions. For example, it can achieve the zero trust mobile solutions by linking with Qi An Xin’s mobile security solutions. It can achieve data access scenarios by linking with Qi An Xin’s data security solutions. It can achieve zero trust solutions for cloud and virtualization scenarios by linking with Qi An Xin’s cloud security management platforms.

3.2. Scheme of Typical Scenarios

Here’s an example of a typical application scenario that describes the logic principle of Qi An Xin Zero Trust Security Solution. The resources including business applications and API services need to be protected in the data subnet. The user and the device in the user subnet need to access business applications, and external applications need to call API services. The scheme logic diagram is shown in Figure 9.

Source Qi An Xin Group, 2019

Source Qi An Xin Group, 2019

Figure 8 Relation between Qi An Xin Zero Trust Security Solution and Reference Framework

Figure 9 Scheme of Typical Scenarios

12

In this scheme, an end-to-end zero trust solution is set up by deploying a logical zero trust access control area between the user subnet and the data subnet. TAP takes over access requests of all the user and device business, and TIP takes over all the external application API call requests. All the access requests are authenticated and dynamically authorized through TAC. TESS continuously carries on the assessment to the device, and TNSS continuously carries on the assessment to the network traffic, and generates the security event to IDA. IDA comprehensively accesses log reports, the security event reports, the identity and authority information and carries on key information and trust evaluation. It acted as the basis of permission determination or revocation for the trust level output from TAC platform.

4. Migration Methodology of Zero Trust As a new security architecture, Zero Trust Architecture has a certain connection with the existing business conditions, security capabilities, and organizational structure of the enterprise. Zero trust migration cannot be accomplished overnight. It is necessary to follow a certain methodology, combine the current situation of the enterprise unify the goal and vision, to make plans properly and construct step by step.

The zero trust migration methodology is shown in Figure 10.

4.1. Define Vision

The construction and operation of zero trust requires the active participation of all the leading departments of enterprise, including Security Department, Business

Source Qi An Xin Group, 2019

Development Department, IT Service Department, Operation Department, and etc. The key decision-makers of the company’s digital transformation should raise the new generation of zero trust security architecture to a strategic level and define a unified vision. It is recommended to establish a dedicated organization (or virtual organization) and assign people with sufficient authority to carry out the whole process of zero trust migration. It is suggested that people at least at the CIO/CSO or level CISO should promote zero trust projects with the support of the company’s senior decision makers.

Usually Security Department’s words are not valued that much in enterprises and security projects are often blocked or even opposed by Business Department. Zero trust is the start point for the initiators of zero trust projects to persuade the Business Department and the company’s senior decision makers.

Figure 10 Migration Methodology of Zero Trust

13

13

In addition, it needs more cooperation and support from departments and personnel during the process of zero trust migration, especially the critical support from its numerous end users, their own ordinary staff. It is also important to suggest that all personnel should enhance their recognition to zero trust security through the continuous security culture activities on company level.

4.2. Plan First

Zero Trust Architecture was born inevitably under the evolution of security thinking and security architecture with focus on the security capabilities of identity, business, trust and adaptive access control and other dimensions, all of which are inseparable, requiring zero trust being a built-in security naturally. The construction path of zero trust should combine the current situation and requirement, embed the core capability of zero trust and the component into the business system, and construct the adaptive built-in security mechanism. It is suggested that make plans at the beginning of business construction and carry on the in-depth aggregation of security and the business.

The purpose of planning is to identify and define the path. Zero Trust Architecture needs to be combed and evaluated from two dimensions, capability maturity and business scope.

The key capabilities of Zero Trust Architecture include: identity-based schema, resource secure access, continuous trust evaluation and adaptive access control. Each key capability can be divided into several skills. The enterprises need to evaluate the current security capabilities, and determine the priority of security capability construction based on the risks, security budget, compliance requirements and other information.

Zero Trust Architecture ultimately needs to cover all the resources of the enterprise and build a protection surface for it. Enterprise resources include applications, APIs, functions, data, etc. During the planning phase, business priorities for migration to zero trust need to be determined. In general, new businesses and core businesses are considered as first priority.

After sorting out the current situation, requirements, business status and priority of security capability, it is necessary to further sort out the exposed surface of the core business, the access subjects and the rights of access subjects of each exposed surface, and determine the initial construction path and the construction scheme of the first phase.

4.3. Construct Step-by-step

The construction phase closely follows the planning. According to the thought orientation of planning, the division of construction phase varies according to different enterprises. If it is a capability- priority construction idea, it is necessary to build a low-to-high capability for a small number of services, verify the complete capability of zero trust through a local business scenario, and then gradually migrate more services. Scope- priority is to migrate as many businesses as possible in a moderate capacity dimension, and then gradually improve the capabilities. Both ideas have their own key points, and the enterprise should select the ideas and divide the construction stages according to the specific conditions in the planning phase.

A proposed step-by-step thought consists of three main steps, proof of concept, application migration, and capability evolution. First, build a medium zero trust security capability and validate the overall scheme in a small business scope; then

optimize some local optimization points in validation process, and move into more business applications for further verification and detect new security requirements; finally, plan the evolution phase of subsequent capacity based on validation results to enhance the zero trust capabilities in all aspects gradually and methodically.

Zero Trust Architecture continues its evolution by improvement and progress of zero trust capability based on business requirements, security operation status and technology development trends.

5. ConclusionZero Trust Architecture reevaluates and examines the traditional perimeter-based security architecture, and gives new suggestions on security architecture idea: By default, any user, device, system, or application shall not be trusted inside and outside the network, instead, the trust base of access control shall be reconstructed based on adaptive authentication, authorization, and encryption technology and be dynamically adjusted based on the trust evaluation of access subjects. It is a brand new security concept and architecture other than a coarse-grained access control on perimeter of enterprise network. The fine-grained access control shall be made to all access requests among the people, devices, business applications and data assets of enterprises. Moreover, the access control strategy should be dynamically adjusted based on trust evaluation of context request. It is a “built-in security” mechanism to deal with threats under the new IT environment.

Source Qi An Xin Group

14

Research from Gartner

Market Guide for Zero Trust Network Access

Zero trust network access replaces traditional technologies, which require companies to extend excessive trust to employees and partners to connect and collaborate. Security and risk management leaders should plan pilot ZTNA projects for employee/partner-facing applications.

Key Findings

• Digital business transformation requires that systems, services, APIs, data and processes be accessible through multiple ecosystems anywhere, anytime, from any device over the internet. This expands the surface area for attackers to target.

• Secure access capabilities must evolve to the cloud, where the users are and where applications and services are moving. Many software-defined perimeter offerings are cloud-based.

• IP addresses and location are no longer practical to establish sufficient trust for network access.

• Zero trust network access provides adaptive, identity-aware, precision access. Removing network location as a position of advantage eliminates excessive implicit trust.

• ZTNA improves flexibility, agility and scalability, enabling digital ecosystems to work without exposing services directly to the internet, reducing risks of distributed denial of service attacks.

• Although virtual private network replacement is a common driver for the adoption of ZTNA, ZTNA can also offer a solution for allowing unmanaged devices to securely access applications.

Recommendations

Security and risk management leaders responsible for secure network access should:

• Go beyond using IP addresses and network location as a proxy for access trust. Use ZTNA for application-level access only after sufficient user and device authentication.

• Replace designs for employee- and partner-facing applications that expose services to direct internet connections. Pilot a ZTNA deployment using a digital business service that needs to be accessible to partners as a use case.

• Phase out legacy VPN-based access for high-risk use cases and begin phasing in ZTNA. This reduces the ongoing need to support widely deployed VPN clients and introduces clientless identity- and device-aware access. Support unmanaged devices for employees.

• Choose ZTNA products/services that expand identity assurance beyond a single factor, which is an important supplement to the ZTNA principle of context-based/adaptive access control.

Strategic Planning Assumptions

By 2022, 80% of new digital business applications opened up to ecosystem partners will be accessed through zero trust network access (ZTNA).

By 2023, 60% of enterprises will phase out most of their remote access virtual private networks (VPNs) in favor of ZTNA.

By 2023, 40% of enterprises will have adopted ZTNA for other use cases described in this research.

Market Definition

ZTNA, which is also known as a software-defined perimeter (SDP), creates an identity- and context-based, logical-access boundary around an application or set of applications. The applications are hidden from discovery, and access is restricted via a trust broker to a set of named entities. The broker verifies the identity, context and policy adherence of the specified participants before allowing access. This removes the application assets from public visibility and significantly reduces the surface area for attack.

Market DescriptionThe old security mindset of “inside means trusted” and “outside means untrusted” is broken in the world of digital business, which

requires anywhere, anytime, any device access to services that may not be located “inside” an on-premises data center. Similarly, the old model expects all programmers to be security engineers, building intrinsically secure networked applications, and incorporating sophisticated authentication and access controls. That does not scale today.

The new model presents an approach in which a trust broker mediates connections between applications and users. ZTNA abstracts away and centralizes the security mechanisms so that the security engineers and staff can be responsible for them. ZTNA starts with a default deny posture of zero trust. It grants access based on identity, plus other attributes and context (such as time/date, geolocation and device posture), and adaptively offers the appropriate trust required at the time. The result is a more resilient environment with improved flexibility and better monitoring. ZTNA will appeal to organizations looking for adaptive and secure ways to connect and collaborate with their digital business ecosystem, remote workers and partners.

ZTNA provides controlled access to resources, reducing the surface area for attack. The isolation afforded by ZTNA improves connectivity, removing the need to directly expose applications to the internet. The internet becomes an untrusted transport and access to applications occurs through an intermediary. The intermediary can be a cloud service controlled by a third-party provider or a self-hosted service. In either case, incoming traffic to applications always passes through the intermediary after users have successfully authenticated to it.

In many cases, entity behavior is continuously monitored for abnormal activity, as described in Gartner’s Continuous Adaptive Risk and Trust Assessment (CARTA) framework. In a sense, ZTNA creates individualized “virtual perimeters” that encompass only the user, the device and the application. ZTNA normalizes the user experience, removing the access distinctions that exist when on, versus off, the corporate network.

15

15

Market Direction

The ZTNA notion has been gaining momentum since an initial specification for software-defined perimeters (SDP) was introduced at the Cloud Security Alliance Summit in 2014. The initial SDP specification addressed web-based applications only, and updates to the specification have lagged, but they are expected later in 2019. Commercial products roughly based on this initial specification are available, as are products based on Google’s BeyondCorp zero trust networking vision — also limited to web-enabled applications only. In addition, a large number of alternative commercial products using other approaches that are not limited to web applications have entered the market.

The ZTNA market is still nascent, but it’s growing quickly. It has piqued the interest of organizations seeking a more flexible alternative to VPNs and those seeking more precise access and session control to applications located on-premises and in the cloud. ZTNA vendors continue to attract venture capital funding. This, in turn, encourages new startups to enter the market and seek ways to differentiate. Merger and acquisition (M&A) activity in this market has begun, with three startup vendors now having been acquired by larger networking, telecommunications and security vendors.

Although ZTNA offerings differ in their technical approaches, they provide generally the same fundamental value proposition:

• Removing applications and services from direct visibility on the public internet.

• Enabling precision (“just in time” and “just enough”) access for named users to specific applications only after an assessment of the identity, device health (highly encouraged) and context has been made.

• Enabling access independent of the user’s physical location or the device’s IP address (except where policy prohibits — e.g., for specific areas of the world). Access policies are based on user, device and application identities.

• Granting access only to the specific application, not the underlying network. This limits the need for excessive access to all ports and protocols or all applications, some of which the user may not be entitled to.

• Providing end-to-end encryption of network communications.

• Providing optional inspection of the traffic stream for excessive risks in the form of sensitive data handling and malware.

• Enabling optional monitoring of the session for indications of unusual activity, duration or bandwidth requirements.

• Providing a consistent user experience for accessing applications — clientless or via a ZTNA client regardless of network location.

Gartner has identified different approaches vendors have adopted as they develop products and services for the market.

Client-Initiated ZTNAThese offerings more closely follow the original Cloud Security Alliance (CSA) SDP specification. An agent installed on authorized devices sends information

about its security context to a controller. The controller prompts the user on the device for authentication and returns a list of allowed applications. After the user and device are authenticated, the controller provisions connectivity from the device through a gateway that shields services from direct internet access. The shielding protects applications from distributed denial of service (DDoS) attacks.

Some products remain in the data path once the controller establishes connectivity; others remove themselves. This approach is difficult, if not impossible, to implement on an unmanaged device, due to the requirement to install an agent. In some cases, a third-party mobile threat defense (MTD) product — which users may be more willing to accept than full device management — can provide a posture assessment to the trust broker. (See Figure 1 for a conceptual model.)

Service-Initiated ZTNAThese models more closely follow the Google BeyondCorp vision. A connector installed in the same network as the application establishes and maintains an outbound connection to the provider’s cloud. Users authenticate to the provider to access protected applications. The provider then typically authenticates to an enterprise

FIGURE 1Conceptual Model of Client-Initiated ZTNA

16

identity management product. Application traffic passes through the provider’s cloud, which provides isolation from direct access via a proxy. Enterprise firewalls require no openings for inbound traffic. However, the provider’s network becomes another element of network security that must be evaluated.

The advantage of this model is that no agent is required on the end user’s device, making it an attractive approach for unmanaged devices. The disadvantage is that the application’s protocols must be based on HTTP/HTTPS, limiting the approach to web applications and protocols such as Secure Shell (SSH) or Remote Desktop Protocol (RDP) over http. (See Figure 2 for a conceptual model.)

Some vendors offer both alternatives. This provides enterprises with the ability to mix and match, as needed, to address specific use cases.

Market Analysis

The internet was designed to connect things easily, not to block connections. The internet uses inherently weak identifiers (specifically, IP addresses) to connect. If you have an IP address and a route, you can connect and communicate to other IP addresses, which were never designed to be authentication

mechanisms. The messy problem of authentication is handled by higher levels of the stack, typically the OS and application layers. For network connectivity, this default allow posture creates an excessive amount of implicit trust.

Attackers abuse this trust. The first companies that connected to the public internet quickly found out that they needed a demarcation point where their internal network connected to the internet. This ultimately created what has become a multibillion dollar market for perimeter firewalls. Networked systems on the inside were “trusted” and free to communicate with each other. External systems were “untrusted” and communications with the outside, inbound or outbound, were blocked by default. If needs arose for communication with the outside, these required a series of exceptions (i.e., holes) in the firewall, which were difficult and cumbersome to maintain and monitor.

This trusted/untrusted network security model is a relatively coarse and crude control, but it was initially effective. However, it creates excessive trust (on the inside) that is abused by attackers from the outside (once they penetrate the defenses and reach the inside). When external access to our systems and services is needed, we typically do one of

two things. For some users, we create a VPN to allow the user to pass through the firewall and connect to the internal network. Once “inside,” the VPN connection is treated as trusted.

Alternatively, we place the front end to the service in a segmented part of the network with direct internet connectivity — referred to as a demilitarized zone (DMZ) — so users can access it. Both alternatives create excessive trust and do little to restrict lateral movement, resulting in latent risk. In the case of VPNs, attackers with credentialed access now have access to our networks. (The Target HVAC breach is an example.) Likewise, if the service is exposed in the DMZ, anyone on the internet — including all the attackers — can see it as well, even if it is protected by a web application firewall (WAF).

Excessive network trust leads to excessive latent risk. This will inevitably be exploited, leading to breaches and bringing legal, financial and regulatory exposure. Network connectivity (even the right to “ping” or see a server) should not be an entitlement; it should be earned based on trust. Gartner believes the time has come to isolate services and applications from the dangers of the public internet, and to provide compartmentalized access only to required applications in any given context. The tremendous increase in the number of internet-connected services, and the growing likelihood that services and users could be located at virtually any IP address, exacerbate the weaknesses of the old model.

Benefits and UsesThe benefits of ZTNA are immediate. Similar to a traditional VPN, services brought within the ZTNA environment are no longer visible on the public internet and, thus, are shielded from attackers. In addition, ZTNA brings significant benefits in user experience, agility, adaptability and ease of policy management. For cloud-based ZTNA offerings, scalability and ease of adoption are additional benefits. ZTNA enables digital business transformation scenarios that are ill-suited to legacy access approaches. As a result of digital transformation efforts, most enterprises will

FIGURE 2Conceptual Model of Service-Initiated ZTNA

17

17

have more applications, services and data outside their enterprises than inside. Cloud-based ZTNA services place the security controls where the users and applications are — in the cloud. Some of the larger ZTNA vendors have invested in dozens of points of presence worldwide for low-latency user/device access.

Several use cases lend themselves to ZTNA:

• Opening applications and services to collaborative ecosystem members, such as distribution channels, suppliers, contractors or retail outlets, without requiring a VPN or DMZ. Access is more tightly coupled to applications and services.

• Normalizing the user experience for application access — ZTNA eliminates the distinction between being on and off the corporate network.

• Carrying encryption all the way to the endpoints for scenarios where you don’t trust the carrier or cloud provider.

• Providing application-specific access for IT contractors and remote or mobile employees as an alternative to VPN-based access.

• Extending access to an acquired organization during M&A activities, without having to configure site-to-site VPN and firewall rules.

• Permitting users in potentially dangerous areas of the world to interact with applications and data in ways that reduce or eliminate the risks that originate in those areas — pay attention to requirements for strong identity and endpoint protection.

• Isolating high-value enterprise applications within the network or cloud to reduce insider threats and affect separation of duties for administrative access.

• Authenticating users on personal devices — ZTNA can improve security and simplify bring your own device (BYOD) programs by reducing full management requirements

and enabling more-secure direct application access.

• Creating secure enclaves of Internet of Things (IoT) devices or a virtual-appliance-based connector on the IoT network segment for connection.

• Cloaking systems on hostile networks, such as systems that would otherwise face the public internet, used for collaboration.

• Enabling SaaS applications to connect back to enterprise systems and data for processes that require SaaS applications to interact with enterprise on-premises or infrastructure as a service (IaaS)-based services.

RisksAlthough ZTNA greatly reduces overall risks, it doesn’t eliminate every risk completely, as these examples illustrate:

• The trust broker could become a single point of any kind of failure. Fully isolated applications using ZTNA will stop working when the ZTNA service is down. Well-designed ZTNA services include physical and geographic redundancy with multiple entry and exit points to minimize the likelihood of outages affecting overall availability. Furthermore, a vendor’s SLA (or lack thereof) can be an indicator of how robust it views their offering. Favor vendors with SLAs that minimize business disruptions.

• Attackers could attempt to compromise the trust broker system. Although unlikely, the risk isn’t zero. ZTNA services built on public clouds or major internet carriers benefit from the provider’s strong tenant isolation mechanisms. Nevertheless, collapse of the tenant isolation would allow an attacker to penetrate the systems of the vendor’s customers and move laterally within and between them. A compromised trust broker should fail over to a redundant one immediately. If it can’t, then it should fail closed — that is, if it can’t deflect abuse, it should disconnect from the internet. Favor vendors who adopt this stance.

• Compromised user credentials could allow an attacker on the local device to observe and exfiltrate information from the device. ZTNA architectures that combine device authentication with user authentication contain this threat to a degree, stopping the attack from propagating beyond the device itself. We suggest that, wherever possible, stronger authentication for access be used.

• Some ZTNA vendors have chosen to focus their developments on supporting web application protocols only (HTTP/HTTPS). Carrying legacy applications and protocols through a ZTNA service could prove to be more difficult.

• The market is in flux, and smaller vendors could disappear or be acquired.

Evaluation FactorsWhen evaluating ZTNA technologies, here are the key questions to ask:

• Does the vendor require that an endpoint agent be installed? What OSs are supported? What mobile devices? How well does the agent behave in the presence of other agents?

• Does the offering support single packet authentication (SPA) as an initial form of identity verification to the trust broker? SPA allows the broker to ignore any attempts to communicate, unless the first attempt contains a specialized, encrypted packet.

• Does the offering provide the ability to perform a security posture assessment of the device (OS version, patch levels, password and encryption policies, etc.), without requiring a unified endpoint management (UEM) tool? Is any option provided for achieving this on unmanaged devices?

• Does the offering integrate with UEM providers, or can the local agent determine device health and security posture as a factor in the access decision? What UEM vendors has the ZTNA vendor partnered with?

18

• What authentication standards does the trust broker support? Is integration with an on-premises directory or cloud-based identity services available? Does the trust broker integrate with the organization’s existing identity provider? Does the trust broker support common options for multifactor authentication (MFA)? Can the provider enforce strong user authentication for administrators?

• Is there user and entity behavior analytics (UEBA) functionality that can identify when something anomalous happens within the ZTNA-protected environment?

• Some ZTNA products are delivered partly or wholly as cloud-based services. Does this meet the organization’s security and residency requirements? Has the vendor undergone one or more third-party attestations, such as SOC 2 or ISO 27001?

• How geographically diverse are the vendor’s entry and exit points (referred to as edge locations and/or points of presence) worldwide? What edge/physical infrastructure providers or colocation facilities does the vendor use?

• What is the vendor’s technical behavior when the ZTNA service comes under sustained attack? Does the service fail closed (thus blocking digital business partners from accessing enterprise services) or does the service fail open? Is it possible to selectively choose fail-closed or fail-open for specific enterprise applications? If fail-open is a requirement, don’t forget to add in other layers of defense to protect applications no longer shielded by the ZTNA service.

• Does the offering support only web applications, or can legacy applications also gain the same security advantages?

• What algorithms and key lengths has the vendor chosen? What third-party certifications has the vendor obtained? Does the vendor’s product description demonstrate an understanding of contemporary cryptographic practices, or

is it laced with too-good-to-be-true crypto “snake oil”?

• After the user and device pass authentication, does the trust broker remain resident in the data path? This approach deserves consideration. Trust brokers that remain in the data path offer greater visibility and can monitor for unusual and suspicious activities. They could, however, become bottlenecks or single points of failure. Designs that include failover support mitigate this concern, but could be vulnerable to DDoS attacks that attempt to bypass inspection.

• Can the vendor provide inspection of session flows and content for inappropriate sensitive data handling, malware detection and unusual behaviors?

• To what extent is partial or full cloaking, or allowing or prohibiting inbound connections, a part of the isolated application’s security requirements? Perhaps the more minimal protection of a content delivery network (CDN) is sufficient. Different enterprise applications might have different requirements.

• Does the provider maintain a bug bounty program and have a credible, responsible, public or private disclosure policy? It is critical for software providers to constantly test for and remove product vulnerabilities. Favor providers that actively do so.

ZTNA AlternativesThere are several alternative approaches to ZTNA:

• Legacy VPNs remain popular, but they might not provide sufficient risk management for exposed services and may be difficult to manage, given the dynamic nature of digital business. Always-on VPNs that require device and user authentication align with the ZTNA model; however, basic network-access VPNs do not. Factor security requirements into VPN models and user satisfaction expectations. For third-party, privileged

access into enterprise systems, a privileged access management (PAM) tool can be a useful alternative to a VPN.

• Exposing web applications through a reverse-proxy-based WAF is another option. With WAF as a service (i.e., cloud WAF), traffic passes through the provider’s WAF service for inspection before delivery to its destination. To avoid false positives or potential application malfunctions, cloud WAFs, like any other WAF, typically require some time for testing and adjusting rules. Because the protected services are still visible to attackers on the public internet, the isolation is limited to the strength of the WAF. However, partner- and employee-facing applications are not normally candidates for WAFs.

• Choosing to retain existing design patterns and exposing digital business applications in traditional DMZs remain alternatives. However, DMZs provide limited isolation against modern attacks (typically a reverse-proxy WAF). Furthermore, DMZs still leave the application discoverable to all attackers.

• A remote browser isolation product offers another option, specifically for the isolation of web-enabled application access. Here, the browser session itself is rendered from the end user’s device and, typically, in a service, from the enterprise network (e.g., a cloud-based remote browser service), providing isolation on both sides.

• CDNs can absorb DDoS attacks, reduce the noise and threats of bot attacks, and guard against website defacement. However, they offer no application-level protection and no anonymity — attackers targeting sites can discover the site is protected with a CDN and might attempt to exploit vulnerabilities present in the CDN. Many CDNs include a basic cloud WAF.

• Applications that don’t require full, interactive internet connectivity, but instead expose only APIs to the public internet could be protected by an API gateway, although ZTNA can also work here. API gateways enforce authentication, validate

19

19

authorization and mediate the correct use of application APIs. This is especially useful if the application lacks mechanisms for ensuring API security. Most API gateways also expose logs of all activity through a native monitoring tool or integration with popular security information and event management (SIEM) tools. Favor API gateways that integrate with enterprise directories and single sign-on (SSO) protocols — or use a ZTNA service instead.

• It is possible to go full IaaS. When ZTNA or other isolation measures are not good enough, moving the application off-enterprise completely is the best alternative. Many of the suggested isolation mechanisms are available to workloads placed in the cloud and are designed more for primary protection, rather than enterprise isolation. The goal shifts to protecting the application and data, with less concern for isolation. However, this still leaves systems exposed to attack, especially if legacy DMZ architectures are replicated in the cloud.

Representative Vendors

The vendors listed in this Market Guide do not imply an exhaustive list. This section is intended to provide more understanding of the market and its offerings.

Market IntroductionZTNA products and services are offered by vendors in one of two ways:

• As a service from the cloud

• As a stand-alone offering that the customer is responsible for supporting

As-a-service offerings (see Table 1) require less setup and maintenance than stand-alone offerings. As-a-service offerings typically require provisioning at the end-user or service side and route traffic through the vendor’s cloud for policy enforcement. Stand-alone offerings (see Table 2) require customers to deploy and manage all elements of the product. In addition, several of the major IaaS cloud providers offer ZTNA capabilities for their customers.

Table 1. Representative Vendors of ZTNA as a Service

Vendor Product or Service Name

Akamai Enterprise Application Access

Cato Networks Cato Cloud

Cisco Duo Beyond (acquisition by Cisco)

CloudDeep Technology (China only) DeepCloud SDP

Cloudflare Cloudflare Access

InstaSafe Secure Access

Meta Networks Network as a Service Platform

New Edge Secure Application Network

Okta Okta Identity Cloud (Acquired ScaleFT)

Perimeter 81 Software Defined Perimeter

SAIFE Continuum

Symantec Luminate Secure Access Cloud (acquisition by Symantec)

Verizon Vidder Precision Access (acquisition)

Zscaler Private Access

Source: Gartner (April 2019)

Table 2. Representative Vendors of Stand-Alone ZTNA

Vendor Product or Service Name

BlackRidge Technology Transport Access Control

Certes Networks Zero Trust WAN

Cyxtera AppGate SDP

Google Cloud Platform (GCP) Cloud Identity-Aware Proxy (Cloud IAP)

Microsoft (Windows only) Azure AD Application Proxy

Pulse Secure Pulse SDP

Safe-T Software-Defined Access Suite

Unisys Stealth

Waverley Labs Open Source Software Defined Perimeter

Zentera Systems Cloud-Over-IP (COiP) Access

Source: Gartner (April 2019)

20

Market Recommendations

Given the significant risk that the public internet represents and the attractiveness of compromising internet-exposed systems to gain a foothold in enterprise systems, enterprises need to consider isolating digital business services from visibility by the public internet. Don’t mistake Gartner’s recommendation for the tried, yet true “security by obscurity is no security at all” axiom. Although ZTNA cloaks services from discovery and reconnaissance, it erects true barriers that are proving to be more challenging for attackers to circumvent than older notions of simple obfuscation.

For legacy VPN access, look for scenarios in which targeted sets of users performing their work through a ZTNA service can provide immediate value in improving the overall security posture of the organization. In most cases, this could be a partner- or employee-facing application. A ZTNA project is a step toward a more widespread zero trust networking (default deny) security posture. Specifically, nothing can communicate (or even see) an application resource until sufficient trust is established, given the risk and current context to extend network connectivity.

For DMZ-based applications, evaluate what sets of users require access. For those applications with a defined set of users, plan to migrate them to a ZTNA service during the next several years. Use the migration of these applications to public cloud IaaS as a catalyst for this architectural shift.

Specific Recommendations• Budget and pilot a ZTNA project to

demonstrate the benefits of ZTNA to the organization.

• Plan for user-to-application mapping. Role-based access control (RBAC) can help with this. Avoid allowing all users to access all applications.

• Identify which applications and workflows are not candidates for ZTNA, and exclude

them from the scope. This includes access to and download of unstructured data not protected by application- and consumer-facing applications.

• The ZTNA market is emerging, so sign only short-term contracts for no more than 12 to 24 months to retain greater vendor selection flexibility as the market grows and matures.

• For most digital business scenarios, favor vendors that offer ZTNA as a service for easier deployment, higher availability and protection against DDoS attacks. Favor vendors that require no openings in firewalls for listening services (inbound connections), which is typical for most as-a-service flavors of ZTNA.

• When security requirements demand an on-premises installation of a ZTNA product, favor vendors that can reduce the number of firewall openings as much as possible.

• If unmanaged devices will be used by named users, plan to deploy a reverse-proxy-based ZTNA product or service to avoid the need for agent installation.

• Ensure that the vendor supports the authentication protocols the organization and partners use now, including the enterprise’s standard identity store, as well as any it expects to use in the future. The wider the available range, the better, including cloud SSO providers and SaaS-delivered access management providers.

• Don’t expect partners to use your identity store. Require support for SAML, OAuth, OIDC and similar identity federation capabilities.

• Evaluate the effectiveness of a vendor’s ability to query other kinds of device agents, such as UEM, endpoint detection and response (EDR) and MTD, to gain additional context for improved adaptive access decisions.

• Attackers will target ZTNA trust brokers. For on-premises ZTNA products, harden the host OSs using a cloud workload protection platform (CWPP) tool that supports on-premises deployments Rely primarily on default deny allow-listing to explicitly define the code allowed to execute on the system. Don’t rely solely on patching to keep the system hardened.

• If you choose a smaller provider, plan for potential acquisitions by placing appropriate clauses in contracts and having a list of alternative providers lined up, if needed.

Note 1. Representative Vendor Selection❋

The vendors named in this guide were selected to represent two types of ZTNA offerings: as-a-service and stand-alone. For these categories, we list the vendors known to Gartner as of April 2019.

Note 2. Gartner’s Initial Market Coverage

This Market Guide provides Gartner’s initial coverage of the market and focuses on the market definition, rationale for the market and market dynamics.

Source: Gartner Research Note G00386774, Steve Riley, Neil MacDonald, Lawrence Orans, 29 April 2019

21

Qi An Xin Group is leading security provider dedicated in protecting critical and valuable internet assets in a wide range of areas including governments, finance, energy, telecom, and etc. Qi An Xin Group is the fastest growing company in the Chinese security market with over 90% consecutive compound annual growth rate since 2015. Under hard work of over 6500 employees, its technologies have been adopted in 90% of government departments, state-owned companies, and large banks. It starts our international development in 2019 and extend our global business in Indonesia, Singapore, Canada, Hong Kong, Macao etc.

Qi An Xin takes “protecting the security in the big data era” as the mission, “data-driven security” as technical thinking, and big data collection and analysis as support to provide escort and protection for enterprise customers.

Qi An Xin’s corporate vision is to comprehensively enhance security protection ability and level of Chinese organizations and enterprises, and build a reliable network environment for economic development. Qi An Xin uses innovative means of “Internet+” such as big data analysis to help Chinese organizations and enterprises better respond to security threats.

Qi An Xin Identity Security Lab, a professional lab under Qi An Xin Group, focusing on “Zero Trust Security Architecture”. The team takes “Zero Trust Security, New Identity Perimeter” as its core concept and explores new type of security architecture in the assumption of “enterprise’s perimeter is vanishing and perimeter-based defense measures are becoming ineffective”. It has launched Qi An Xin Zero Trust Security Solution with four key capabilities: identity-based schema, resource secure access, continuous trust evaluation and adaptive access control. The team has invested heavily in the research of Zero Trust Security Architecture and product standardization and actively pushed forward the deployment and implementation of the architecture, whose program has been deployed in the central government agencies and state-owned enterprises and highly recognized by the market and the industry.

About Qi An Xin Group