ZERO TRUST ARCHITECTURE - DIGITAL TRUST FRAMEWORK

DIGITAL TRUST
FRAMEWORK (DTF)
Maganathin Veeraragaloo
7th December 2021

The TMForum's Open Digital Architecture (ODA)will be used as
the cornerstone for this Framework
https://www.tmforum.org/oda/
ODA was initially designed for the Telecommunications Industry
inclusive of 5G Services.
The Digital Trust Framework is developed for the 4IR Environment
The Digital Trust Framework (DTF) will be a blueprint for modular,
cloud-based, open digital platforms that can be orchestrated using AI
ODA will be integrated with COBIT 2019, ITIL 4 and ISO 27005 RISK
MANAGER – this is to ensure an overall Digital Trust approach for a
continuous evolving SYSTEMS Environment

Transformation Tools
As-Is
Applications
Transformation
Toolkits
Maturity Tools
Metrics
Maturity
Models
Data
Benchmark
Data
AI Training
Data
DIGITAL TRUST
FRAMEWORK
DIGITAL
TRUST
ARCHITECTURE
Governance
Concepts & Principles
Design Guides
Microservices
Architecture
Governance
AI Governance
Data Governance
Security Governance
Agile
Lifecycle
Management
Business
Deployment & Run
Information Systems
Implementation
Business Capability
Repository
Process Framework
Information
Framework
Integration
Framework
Functional
Framework &
Architecture
Canvas
Operation
Frameworks
Reference
Implementation
Technical
Architecture
Components
Open API’s
Data Model

ITIL 4
Capability Framework
DIGITAL TRUST
FRAMEWORK
Governance &
Processes
Cybersecurity Mesh
Architecture

Zero Trust Security Framework Foundation
SOURCE: https://www.zpesystems.com/solutions/improve-network-
security/zero-trust-security-with-nodegrid/

Zero trust is a security principle which emphasizes that
security networks should “always verify, never trust” any
device, including those already within the network
perimeter.
As a result, a zero trust security framework demands that
any device accessing network resources provide
authentication through micro-segmented security
checkpoints to minimize user error and provide a more
secure network interaction.
Secure your deployments with device geofencing & GPS tracking
Get strong integrity using hardware & software encryption via
TPM
Protect users & data with multi-factor authentication & fine-grain
authorization

Traditional “castle and moat” security models don’t
address either the user error involved in modern
cyberattacks or the expansion of the network perimeter
due to the rise of remote work.
Instead, a zero trust security framework focuses on the
devices themselves and disregards the perimeter as the
primary judge of a device’s trustworthiness.
Protect the entire enterprise, including remote workers
Get core-to-edge data protection & stay safe from attacks
Set up new networks with hardened security, even before Day 0

ZERO TRUST ARCHITECTURE - DIGITAL TRUST FRAMEWORK

ZT is not a single architecture but a set of guiding principles
for workflow, system design and operations that can be used to
improve the security posture of any classification or sensitivity
level [FIPS199].
Transitioning to ZTA is a journey concerning how an
organization evaluates risk in its mission and cannot simply be
accomplished with a wholesale replacement of technology.
That said, many organizations already have elements of a ZTA
in their enterprise infrastructure today.
Organizations should seek to incrementally implement zero
trust principles, process changes, and technology solutions that
protect their data assets and business functions by use case.
Most enterprise infrastructures will operate in a hybrid zero
trust/perimeter-based mode while continuing to invest in IT
modernization initiatives and improve organization business
processes

Zero trust is a cybersecurity paradigm focused on resource protection and the premise
that trust is never granted implicitly but must be continually evaluated.
Zero trust architecture is an end-to end approach to enterprise resource and data
security that encompasses identity (person and non-person entities), credentials,
access management, operations, endpoints, hosting environments, and the
interconnecting infrastructure.
The initial focus should be on restricting resources to those with a need to access and
grant only the minimum privileges (e.g., read, write, delete) needed to perform the
mission.
Traditionally, agencies (and enterprise networks in general) have focused on perimeter
defence and authenticated subjects are given authorized access to a broad collection of
resources once on the internal network.
As a result, unauthorized lateral movement within the environment has been one of
the biggest challenges for organisations.
The Trusted Internet Connections (TIC) and agency perimeter firewalls provide strong
internet gateways.
This helps block attackers from the internet, but the TICs and perimeter firewalls are
less useful for detecting and blocking attacks from inside the network and cannot
protect subjects outside of the enterprise perimeter (e.g., remote workers, cloud-based
services, edge devices, etc.).
SOURCE: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-

An operative definition of zero trust and zero trust
architecture is as follows:
Zero trust (ZT) provides a collection of concepts and ideas designed
to minimize uncertainty in enforcing accurate, least privilege per-
request access decisions in information systems and services in
the face of a network viewed as compromised. Zero trust
architecture (ZTA) is an enterprise’s cybersecurity plan that
utilizes zero trust concepts and encompasses component
relationships, workflow planning, and access policies. Therefore, a
zero trust enterprise is the network infrastructure (physical and
virtual) and operational policies that are in place for an enterprise
as a product of a zero trust architecture plan.

To lessen uncertainties (as they cannot be eliminated), the
focus is on authentication, authorization, and shrinking
implicit trust zones while maintaining availability and
minimizing temporal delays in authentication
mechanisms.
Access rules are made as granular as possible to enforce
least privileges needed to perform the action in the
request.

Access is granted through a policy decision point (PDP)
and corresponding policy enforcement point (PEP).
Zero Trust Access
The system must ensure that the subject is authentic and the
request is valid.
The PDP/PEP passes proper judgment to allow the subject to
access the resource.
This implies that zero trust applies to two basic areas:
authentication and authorization.

What is the level of confidence about the subject’s identity for this unique request?
Is access to the resource allowable given the level of confidence in the subject’s identity?
Does the device used for the request have the proper security posture?
Are there other factors that should be considered and that change the confidence level (e.g.,
time, location of subject, subject’s security posture)?
Overall, enterprises need to develop and maintain dynamic risk-based policies for resource
access and set up a system to ensure that these policies are enforced correctly and
consistently for individual resource access requests.
This means that an enterprise should not rely on implied trustworthiness wherein if the
subject has met a base authentication level (e.g., logging into an asset), all subsequent
resource requests are assumed to be equally valid.
Zero Trust Access

 The “implicit trust zone” represents an area where all the entities are trusted to at least the
level of the last PDP/PEP gateway.
 For example, consider the passenger screening model in an airport. All passengers pass through
the airport security checkpoint (PDP/PEP) to access the boarding gates.
 The passengers, airport employees, aircraft crew, etc., mill about in the terminal area, and all
the individuals are considered trusted. In this model, the implicit trust zone is the boarding
area.
 The PDP/PEP applies a set of controls so that all traffic beyond the PEP has a common level of
trust. The PDP/PEP cannot apply additional policies beyond its location in the flow of traffic. To
allow the PDP/PEP to be as specific as possible, the implicit trust zone must be as small as
possible.
 Zero trust provides a set of principles and concepts around moving the PDP/PEPs closer to the
resource. The idea is to explicitly authenticate and authorize all subjects, assets and workflows
that make up the enterprise.
Zero Trust Access

1. Tenets of Zero Trust
A zero trust architecture is designed and deployed with adherence to the
following zero trust basic tenets:
i. All data sources and computing services are considered resources.
A network may be composed of multiple classes of devices.
A network may also have small footprint devices that send data to
aggregators/storage, software as a service (SaaS), systems sending
instructions to actuators, and other functions.
Also, an enterprise may decide to classify personally owned devices as
resources if they can access enterprise-owned resources.
ii. All communication is secured regardless of network location.
Network location alone does not imply trust.
Access requests from assets located on enterprise-owned network
infrastructure (e.g., inside a legacy network perimeter) must meet the
same security requirements as access requests and communication from
any other non-enterprise-owned network.
In other words, trust should not be automatically granted based on the
device being on enterprise network infrastructure.
All communication should be done in the most secure manner available,
protect confidentiality and integrity, and provide source authentication.

iii. Access to individual enterprise resources is granted on a per-session
basis.
A network may be composed of multiple classes of devices.
Trust in the requester is evaluated before the access is granted.
Access should also be granted with the least privileges needed to complete the
task.
This could mean only “sometime recently” for this particular transaction and
may not occur directly before initiating a session or performing a transaction
with a resource.
However, authentication and authorization to one resource will not
automatically grant access to a different resource.

A zero trust architecture is designed and deployed with adherence to the following zero trust basic
tenets:
iv. Access to resources is determined by dynamic policy—including the observable state of
client identity, application/service, and the requesting asset—and may include other
behavioural and environmental attributes.
 An organization protects resources by defining what resources it has, who its members are (or
ability to authenticate users from a federated community), and what access to resources those
members need.
 For zero trust, client identity can include the user account (or service identity) and any associated
attributes assigned by the enterprise to that account or artifacts to authenticate automated tasks.
 Requesting asset state can include device characteristics such as software versions installed,
network location, time/date of request, previously observed behaviour, and installed credentials.
 Behavioural attributes include, but not limited to, automated subject analytics, device analytics, and
measured deviations from observed usage patterns.
 Policy is the set of access rules based on attributes that an organization assigns to a subject, data
asset, or application.
 Environmental attributes may include such factors as requestor network location, time, reported
active attacks, etc.
 These rules and attributes are based on the needs of the business process and acceptable level of
risk. Resource access and action permission policies can vary based on the sensitivity of the
resource/data. Least privilege principles are applied to restrict both visibility and accessibility.

v. The enterprise monitors and measures the integrity and security
posture of all owned and associated assets.
No asset is inherently trusted. The enterprise evaluates the security posture of
the asset when evaluating a resource request.
An enterprise implementing a ZTA should establish a continuous diagnostics
and mitigation (CDM) or similar system to monitor the state of devices and
applications and should apply patches/fixes as needed.
Assets that are discovered to be subverted, have known vulnerabilities, and/or
are not managed by the enterprise may be treated differently (including denial
of all connections to enterprise resources) than devices owned by or associated
with the enterprise that are deemed to be in their most secure state. This may
also apply to associated devices (e.g., personally owned devices) that may be
allowed to access some resources but not others. This, too, requires a robust
monitoring and reporting system in place to provide actionable data about the
current state of enterprise resources.

vi. All resource authentication and authorization are dynamic and
strictly enforced before access is allowed.
This is a constant cycle of obtaining access, scanning and assessing threats,
adapting, and continually re-evaluating trust in ongoing communication.
An enterprise implementing a ZTA would be expected to have Identity,
Credential, and Access Management (ICAM) and asset management systems in
place.
This includes the use of multifactor authentication (MFA) for access to some or
all enterprise resources.
Continual monitoring with possible reauthentication and reauthorization occurs
throughout user transactions, as defined and enforced by policy (e.g., time-
based, new resource requested, resource modification, anomalous subject
activity detected) that strives to achieve a balance of security, availability,
usability, and cost-efficiency.

A zero trust architecture is designed and deployed with adherence to the following zero
trust basic tenets:
vii. The enterprise collects as much information as possible about the current state of
assets, network infrastructure and communications and uses it to improve its
security posture.
 An enterprise should collect data about asset security posture, network traffic and access
requests, process that data, and use any insight gained to improve policy creation and
enforcement. This data can also be used to provide context for access requests from
subjects
The above tenets attempt to be technology agnostic. For example, “user identification (ID)”
could include several factors such as username/password, certificates, and onetime
password.
These tenets apply to work done within an organization or in collaboration with one or
more partner organizations and not to anonymous public or consumer-facing business
processes.
An organization cannot impose internal policies on external actors (e.g., customers or
general internet users) but may be able to implement some ZT-based policies on non-
enterprise users who have a special relationship with the organization (e.g. registered
customers, employee dependents, etc.)

2. A Zero Trust View of a Network
There are some basic assumptions for network connectivity for any organization that utilizes
ZTA in network planning and deployment.
Some of these assumptions apply to enterprise-owned network infrastructure, and some apply to
enterprise-owned resources operating on no-nenterprise-owned network infrastructure (e.g.,
public Wi-Fi or public cloud providers). These assumptions are used to direct the formation of a
ZTA.
The network in an enterprise implementing a ZTA should be developed with the ZTA tenets
outlined above and with the following assumptions.

1. The entire enterprise private network is not considered an implicit trust zone.
a. Assets should always act as if an attacker is present on the enterprise network, and
communication should be done in the most secure manner available (see tenet 2
above).
b. This entails actions such as authenticating all connections and encrypting all traffic.
2. Devices on the network may not be owned or configurable by the enterprise.
a. Visitors and/or contracted services may include non-enterprise-owned assets that need
network access to perform their role.
b. This includes bring-your-own-device (BYOD) policies that allow enterprise subjects to
use non-enterprise-owned devices to access enterprise resources.
3. No resource is inherently trusted.
a. Every asset must have its security posture evaluated via a PEP before a request is
granted to an enterprise-owned resource (similar to tenet 6 above for assets as well as
subjects).
b. This evaluation should be continual for as long as the session lasts.
c. Enterprise-owned devices may have artifacts that enable authentication and provide a
confidence level higher than the same request coming from non-enterprise-owned
devices.
d. Subject credentials alone are insufficient for device authentication to an enterprise
resource.

4. Not all enterprise resources are on enterprise-owned infrastructure.
a. Resources include remote enterprise subjects as well as cloud services.
b. Enterprise-owned or - managed assets may need to utilize the local (i.e., non-
enterprise) network for basic connectivity and network services (e.g., DNS resolution).
5. Remote enterprise subjects and assets cannot fully trust their local network
connection.
a. Remote subjects should assume that the local (i.e., non-enterprise-owned) network is
hostile.
b. Assets should assume that all traffic is being monitored and potentially modified.
c. All connection requests should be authenticated and authorized, and all
communications should be done in the most secure manner possible (i.e., provide
confidentiality, integrity protection, and source authentication). See the tenets of ZTA
above.
6. Assets and workflows moving between enterprise and non-enterprise infrastructure
should have a consistent security policy and posture.
a. Assets and workloads should retain their security posture when moving to or from
enterprise-owned infrastructure.
b. This includes devices that move from enterprise networks to non-enterprise networks
(i.e. remote users).
c. This also includes workloads migrating from on-premises data centres to non-
enterprise cloud instances.

There are numerous logical components that make up a ZTA deployment
in an enterprise.
These components may be operated as an on-premises service or through a
cloud-based service.
The conceptual framework model shows the basic relationship between the
components and their interactions.
Note that this is an ideal model showing logical components and their
interactions.
From the Figure, the policy decision point (PDP) is broken down into two
logical components: the policy engine and policy administrator (defined
below).
The ZTA logical components use a separate control plane to communicate,
while application data is communicated on a data plane.

Core Zero Trust Logical Components

The component descriptions:
Policy Engine (PE):
This component is responsible for the ultimate decision to grant
access to a resource for a given subject. The PE uses enterprise
policy as well as input from external sources (e.g., CDM
systems, threat intelligence services described below) as input
to a trust algorithm to grant, deny, or revoke access to the
resource. The
PE is paired with the policy administrator component.
The policy engine makes and logs the decision (as approved, or
denied), and the policy administrator executes the decision.

 Policy Administrator (PA):
 This component is responsible for establishing and/or shutting down the communication
path between a subject and a resource (via commands to relevant PEPs).
 It would generate any session-specific authentication and authentication token or
credential used by a client to access an enterprise resource.
 It is closely tied to the PE and relies on its decision to ultimately allow or deny a session.
 If the session is authorized and the request authenticated, the PA configures the PEP to
allow the session to start.
 If the session is denied (or a previous approval is countermanded), the PA signals to the
PEP to shut down the connection.
 Some implementations may treat the PE and PA as a single service; here, it is divided
into its two logical components. The PA communicates with the PEP when creating the
communication path. This communication is done via the control plane.

Policy Enforcement Point (PEP):
 This system is responsible for enabling, monitoring, and eventually
terminating connections between a subject and an enterprise resource.
 The PEP communicates with the PA to forward requests and/or receive
policy updates from the PA.
 This is a single logical component in ZTA but may be broken into two
different components: the client (e.g., agent on a laptop) and resource side
(e.g., gateway component in front of resource that controls access) or a
single portal component that acts as a gatekeeper for communication
paths.
 Beyond the PEP is the trust zone hosting the enterprise resource.

In addition to the core components in an enterprise implementing a ZTA, several data sources
provide input and policy rules used by the policy engine when making access decisions. These
include local data sources as well as external (i.e., non-enterprise-controlled or -created) data
sources. These can include:
 Continuous Diagnostics and Mitigation (CDM) system:
 This gathers information about the enterprise asset’s current state and applies updates
to configuration and software components.
 An enterprise CDM system provides the policy engine with the information about the
asset making an access request, such as whether it is running the appropriate patched
operating system (OS), the integrity of enterprise-approved software components or
presence of non-approved components and whether the asset has any known
vulnerabilities.
 CDM systems are also responsible for identifying and potentially enforcing a subset of
polices on non-enterprise devices active on enterprise infrastructure.

In addition to the core components in an enterprise implementing a ZTA,
several data sources provide input and policy rules used by the policy engine
when making access decisions. These include local data sources as well as
external (i.e., non-enterprise-controlled or -created) data sources. These can
include:
Industry Compliance System:
 This ensures that the enterprise remains compliant with any regulatory
regime that it may fall under (e.g., FISMA, healthcare or financial
industry information security requirements).
 This includes all the policy rules that an enterprise develops to ensure
compliance.

The Component Descriptions:
include:
Threat intelligence feed(s):
 This provides information from internal or external sources that help the
policy engine make access decisions.
 These could be multiple services that take data from internal and/or
multiple external sources and provide information about newly discovered
attacks or vulnerabilities.
 This also includes newly discovered flaws in software, newly identified
malware, and reported attacks to other assets that the policy engine will

include:
Network and System Activity Logs:
 This enterprise system aggregates asset logs, network traffic, resource
access actions, and other events that provide real-time (or near real-time)
feedback on the security posture of enterprise information systems.
 (P.S. Observability can be added here to integrate with Log Collection)

In addition to the core components in an enterprise implementing a ZTA, several
data sources provide input and policy rules used by the policy engine when
making access decisions. These include local data sources as well as external
(i.e., non-enterprise-controlled or -created) data sources. These can include:
Data Access Policies:
 These are the attributes, rules, and policies about access to enterprise
resources.
 This set of rules could be encoded in (via management interface) or
dynamically generated by the policy engine.
 These policies are the starting point for authorizing access to a resource as
they provide the basic access privileges for accounts and
applications/services in the enterprise.
 These policies should be based on the defined mission roles and needs of
the organization.

In addition to the core components in an enterprise implementing a ZTA, several
data sources provide input and policy rules used by the policy engine when
making access decisions. These include local data sources as well as external
(i.e., non-enterprise-controlled or -created) data sources. These can include:
Enterprise Public Key Infrastructure (PKI):
 This system is responsible for generating and logging certificates issued by
the enterprise to resources, subjects, services and applications.
 This also includes the global certificate authority ecosystem and the
Federal PKI,4 which may or may not be integrated with the enterprise
PKI.
 This could also be a PKI that is not built upon X.509 certificates.

In addition to the core components in an enterprise implementing a ZTA, several data sources
provide input and policy rules used by the policy engine when making access decisions. These
include local data sources as well as external (i.e., non-enterprise-controlled or -created) data
sources. These can include:
 ID Management System:
 This is responsible for creating, storing, and managing enterprise user accounts and
identity records (e.g., lightweight directory access protocol (LDAP) server).
 This system contains the necessary subject information (e.g., name, email address,
certificates) and other enterprise characteristics such as role, access attributes, and
assigned assets.
 This system often utilizes other systems (such as a PKI) for artifacts associated with user
accounts.
 This system may be part of a larger federated community and may include non-enterprise
employees or links to non-enterprise assets for collaboration.

In addition to the core components in an enterprise implementing a
ZTA, several data sources provide input and policy rules used by the
policy engine when making access decisions. These include local data
sources as well as external (i.e., non-enterprise-controlled or -
created) data sources. These can include:
Security information and event management (SIEM) system:
This collects security centric information for later analysis.
This data is then used to refine policies and warn of possible
attacks against enterprise assets.

There are several ways that an enterprise can enact a ZTA for workflows.
These approaches vary in the components used and in the main source of policy
rules for an organization.
Each approach implements all the tenets of ZT but may use one or two (or one
component) as the main driver of policies.
A full ZT solution will include elements of all three approaches.
The approaches include enhanced identity governance–driven, logical micro-
segmentation, and network-based segmentation.
Certain approaches lend themselves to some use cases more than others.
An organization looking to develop a ZTA for its enterprise may find that its
chosen use case and existing policies point to one approach over others.
That does not mean the other approaches would not work but rather that other
approaches may be more difficult to implement and may require more
fundamental changes to how the enterprise currently conducts business flows.

1. ZTA Using Enhanced Identity Governance
The enhanced identity governance approach to developing a ZTA uses the
identity of actors as the key component of policy creation.
If it were not for subjects requesting access to enterprise resources, there
would be no need to create access polices.
For this approach, enterprise resource access policies are based on identity
and assigned attributes.
The primary requirement for resource access is based on the access privileges
granted to the given subject.
Other factors such as device used, asset status, and environmental factors
may alter the final confidence level calculation (and ultimate access
authorization) or tailor the result in some way, such as granting only partial
access to a given data source based on network location.
Individual resources or PEP components protecting the resource must have a
way to forward requests to a policy engine service or authenticate the subject
and approve the request before granting access.

1. ZTA Using Enhanced Identity Governance
Enhanced identity governance-based approaches for enterprises are often employed
using an open network model or an enterprise network with visitor access or
frequent non-enterprise devices on the network.
Network access is initially granted to all assets but access to enterprise resources are
restricted to identities with the appropriate access privileges.
There is a downside in granting basic network connectivity as malicious actors could
still attempt network reconnaissance and/or use the network to launch denial of
service attacks either internally or against a third party.
 Enterprises still need to monitor and respond to such behaviour before it impacts
workflows.
The identity-driven approach works well with the resource portal model since device
identity and status provide secondary support data to access decisions.
Other models work as well, depending on policies in place.
Identity-driven approaches also work well for enterprises that use cloud-based
applications/services that may not allow for enterprise-owned or -operated ZT
security components to be used (such as many SaaS offerings).
The enterprise can use the identity of requestors to form and enforce policy on these
platforms or authenticate the subject and approve the request before granting access.

2. ZTA Using Micro-Segmentation
An enterprise may choose to implement a ZTA based on placing individual or
groups of resources on a unique network segment protected by a gateway
security component.
In this approach, the enterprise places infrastructure devices such as
intelligent switches (or routers) or next generation firewalls (NGFWs) or
special purpose gateway devices to act as PEPs protecting each resource or
small group of related resources.
Alternatively (or additionally), the enterprise may choose to implement host-
based micro-segmentation using software agents or firewalls on the endpoint
asset(s).
These gateway devices dynamically grant access to individual requests from
a client, asset or service.
Depending on the model, the gateway may be the sole PEP component or
part of a multipart PEP consisting of the gateway and client-side agent.

2. ZTA Using Micro-Segmentation
This approach applies to a variety of use cases and deployment models
as the protecting device acts as the PEP, with management of said
devices acting as the PE/PA component.
This approach requires an identity governance program (IGP) to fully
function but relies on the gateway components to act as the PEP that
shields resources from unauthorized access and/or discovery.
The key necessity to this approach is that the PEP components are
managed and should be able to react and reconfigure as needed to
respond to threats or change in the workflow.
It is possible to implement some features of a micro-segmented
enterprise by using less advanced gateway devices and even stateless
firewalls, but the administration cost and difficulty to quickly adapt to
changes make this a very poor choice.

3. ZTA Using Network Infrastructure and Software Defined
Perimeters
The last approach uses the network infrastructure to implement a ZTA.
The ZTA implementation could be achieved by using an overlay network (i.e., layer 7
but also could be set up lower of the OSI network stack).
These approaches are sometimes referred to as software defined perimeter (SDP)
approaches and frequently include concepts from Software Defined Networks (SDN)
and intent-based networking (IBN).
In this approach, the PA acts as the network controller that sets up and reconfigures
the network based on the decisions made by the PE.
The clients continue to request access via PEPs, which are managed by the PA
component.
When the approach is implemented at the application network layer (i.e., layer 7),
the most common deployment model is the agent/gateway.
In this implementation, the agent and resource gateway (acting as the single PEP
and configured by the PA) establish a secure channel used for communication
between the client and resource.
There may be other variations of this model, as well for cloud virtual networks, non-
IP based networks, etc.

All of the above components are logical components.
They do not necessarily need to be unique systems.
A single asset may perform the duties of multiple logical components, and likewise, a
logical component may consist of multiple hardware or software elements to perform the
tasks. For example, an enterprise-managed PKI may consist of one component
responsible for issuing certificates for devices and another used for issuing certificates to
end users, but both use intermediate certificates issued from the same enterprise root
certificate authority.
In some ZT product offerings currently available on the market, the PE and PA
components are combined in a single service.
There are several variations on deployment of selected components of the architecture
that are outlined in the sections below.
Depending on how an enterprise network is set up, multiple ZTA deployment models may
be in use for different business processes in one enterprise.

1. Device Agent/Gateway-Based Deployment
In this deployment model, the PEP is divided into two components that
reside on the resource or as a component directly in front of a resource.
For example, each enterprise-issued asset has an installed device agent
that coordinates connections, and each resource has a component (i.e.,
gateway) that is placed directly in front so that the resource
communicates only with the gateway, essentially serving as a proxy for
the resource.
The agent is a software component that directs some (or all) traffic to
the appropriate PEP in order for requests to be evaluated.
The gateway is responsible for communicating with the policy
administrator and allowing only approved communication paths
configured by the policy administrator.

In a typical scenario, a subject with an enterprise-issued laptop wishes to connect to an
enterprise resource (e.g., human resources application/database).
The access request is taken by the local agent, and the request is forwarded to the policy
administrator. The policy administrator and policy engine could be an enterprise local
asset or a cloud-hosted service.
The policy administrator forwards the request to the policy engine for evaluation.
Device Agent/Gateway Model

If the request is authorized, the policy administrator configures a communication
channel between the device agent and the relevant resource gateway via the
control plane.
This may include information such as an internet protocol (IP) address, port
information, session key, or similar security artifacts.
The device agent and gateway then connect, and encrypted application/service
data flows begin.
The connection between the device agent and resource gateway is terminated
when the workflow is completed or when triggered by the policy administrator
due to a security event (e.g., session time-out, failure to reauthenticate).
This model is best utilized for enterprises that have a robust device management
program in place as well as discrete resources that can communicate with the
gateway.
For enterprises that heavily utilize cloud services, this is a client-server
implementation of the Cloud Security Alliance (CSA) Software Defined Perimeter
(SDP) [CSA-SDP]. This model is also appropriate for enterprises that do not want
a BYOD policy in place.
Access is possible only via the device agent, which can be placed on enterprise-
owned assets.

2. Enclave-Based Deployment
This deployment model is a variation of the device agent/gateway model
above.
In this model, the gateway components may not reside on assets or in
front of individual resources but instead reside at the boundary of a
resource enclave (e.g., on-location data center) as shown in the Figure.
Usually, these resources serve a single business function or may not be
able to communicate directly to a gateway (e.g., legacy database system
that does not have an application programming interface [API] that can be
used to communicate with a gateway).
This deployment model may also be useful for enterprises that use cloud-
based micro-services for a single business processes (e.g., user notification,
database lookup, salary disbursement).
In this model, the entire private cloud is located behind a gateway visible
only via the device agent, which can be placed on enterprise-owned assets.

It is possible for this model to be a hybrid with the device agent/gateway
model.
In this model, enterprise assets have a device agent that is used to connect
to enclave gateways, but these connections are created using the same
process as the basic device agent/gateway model.
This model is useful for enterprises that have legacy applications or on-
premises data centres that cannot have individual gateways in place.
The enterprise needs a robust asset and configuration management
program in place to install/configure the device agents.
The downside is that the gateway protects a collection of resources and
may not be able to protect each resource individually.
This may also allow for subjects to see resources which they do not have
privileges to access. .

Enclave Gateway Model

3. Resource Portal-Based Deployment
In this deployment model, the PEP is a single component that acts as a
gateway for subject requests.
The gateway portal can be for an individual resource or a secure enclave for
a collection of resources used for a single business function.
One example would be a gateway portal into a private cloud or data centre
containing legacy applications as shown in the Figure.
The primary benefit of this model over the others is that a software
component does not need to be installed on all client devices.
This model is also more flexible for BYOD policies and interorganizational
collaboration projects. Enterprise administrators do not need to ensure that
each device has the appropriate device agent before use.
However, limited information can be inferred from devices requesting
access.
This model can only scan and analyse assets and devices once they connect
to the PEP portal and may not be able to continuously monitor them for
malware, unpatched vulnerabilities, and appropriate configuration.

Resource Portal Model

The main difference with this model is there is no local agent that handles
requests, and so the enterprise may not have full visibility or arbitrary
control over assets as it can only see/scan them when they connect to a
portal.
The enterprise may be able to employ measures such as browser isolation to
mitigate or compensate.
These assets may be invisible to the enterprise between these sessions.
This model also allows attackers to discover and attempt to access the
portal or attempt a denial-of-service (DoS) attack against the portal.
The portal systems should be well provisioned to provide availability
against a DoS attack or network disruption.

4. Device Application Sandboxing
Another variation of the agent/gateway deployment model is having vetted applications or processes
run compartmentalized on assets.
These compartments could be virtual machines, containers, or some other implementation, but the
goal is the same: to protect the application or instances of applications from a possibly compromised
host or other applications running on the asset.
Application Sandboxes

4. Device Application Sandboxing
In the Figure, the subject device runs approved, vetted applications in a sandbox.
The applications can communicate with the PEP to request access to resources, but
the PEP will refuse requests from other applications on the asset.
The PEP could be an enterprise local service or a cloud service in this model. The
main advantage of this model variant is that individual applications are segmented
from the rest of the asset.
If the asset cannot be scanned for vulnerabilities, these individual, sandboxed
applications may be protected from a potential malware infection on the host asset.
One of the disadvantages of this model is that enterprises must maintain these
sandboxed applications for all assets and may not have full visibility into client
assets.
The enterprise also needs to make sure each sandboxed application is secure,
which may require more effort than simply monitoring devices.

For an enterprise with a ZTA deployment, the policy engine
can be thought of as the brain and the PE’s trust algorithm as
its primary thought process.
The trust algorithm (TA) is the process used by the policy
engine to ultimately grant or deny access to a resource.
The policy engine takes input from multiple sources: the policy
database with observable information about subjects, subject
attributes and roles, historical subject behaviour patterns,
threat intelligence sources, and other metadata sources.
The process can be grouped into broad categories and
visualized in the Figure.

In the figure, the inputs can be broken into categories based on
what they provide to the trust algorithm.
Access Request:
This is the actual request from the subject.
The resource requested is the primary information used, but
information about the requester is also used.
This can include OS version, software used (e.g., does the
requesting application appear on a list of approved
applications?), and patch level.
Depending on these factors and the asset security posture,
access to assets might be restricted or denied.

In the figure, the inputs can be broken into categories based on what they provide
to the trust algorithm.
Subject Database:
This is the “who” that is requesting access to a resource [SP800-63].
This is the set of subjects (human and processes) of the enterprise or
collaborators and a collection of subject attributes/privileges assigned.
These subjects and attributes form the basis of policies for resource access
[SP800-162] [NISTIR 7987].
User identities can include a mix of logical identity (e.g., account ID) and
results of authentication checks performed by PEPs.
Attributes of identity that can be factored into deriving the confidence level
include time and geolocation.
A collection of privileges given to multiple subjects could be thought of as a
role, but privileges should be assigned to a subject on an individual basis
and not simply because they may fit into a particular role in the
organization.
This collection should be encoded and stored in an ID management system
and policy database. This may also include data about past observed subject
behaviour in some (TA) variants.

Asset Database (and observable status):
This is the database that contains the known status of each
enterprise-owned (and possibly known non-enterprise/
BYOD) asset (physical and virtual, to some extent).
This is compared to the observable status of the asset
making the request and can include OS version, software
present, and its integrity, location (network location and
geolocation), and patch level.
Depending on the asset state compared with this database,
access to assets might be restricted or denied.

Resource Requirements:
This set of policies complements the user ID and attributes
database [SP800-63] and defines the minimal requirements
for access to the resource.
Requirements may include authenticator assurance levels,
such as MFA network location (e.g., deny access from
overseas IP addresses), data sensitivity, and requests for
asset configuration.
These requirements should be developed by both the data
custodian (i.e., those responsible for the data) and those
responsible for the business processes that utilize the data
(i.e., those responsible for the mission).

Threat intelligence:
This is an information feed or feeds about general threats
and active malware operating on the internet.
This could also include specific information about
communication seen from the device that may be suspect
(such as queries for possible malware command and control
nodes).
These feeds can be external services or internal scans and
discoveries and can include attack signatures and
mitigations.
This is the only component that will most likely be under
the control of a service rather than the enterprise.

The final determination is then passed to the PA for execution.
The PA’s job is to configure the necessary PEPs to enable
authorized communication.
Depending on how the ZTA is deployed, this may involve
sending authentication results and connection configuration
information to gateways and agents or resource portals.
PAs may also place a hold or pause on a communication session
to reauthenticate and reauthorize the connection in accordance
with policy requirements.
The PA is also responsible for issuing the command to terminate
the connection based on policy (e.g., after a time-out, when the
workflow has been completed, due to a security alert).

1. Trust Algorithm Variations
There are different ways to implement a TA.
Different implementers may wish to weigh the above factors
differently according to the factors’ perceived importance.
There are two other major characteristics that can be used to
differentiate TAs.
The first is how the factors are evaluated, whether as binary
decisions or weighted parts of a whole “score” or confidence
level.
The second is how requests are evaluated in relation to other
requests by the same subject, application/service, or device
 The PA’s job is to configure the necessary PEPs to enable
authorized communication.

a. Criteria- versus Score-Based:
A criteria-based TA assumes a set of qualified attributes that must be
met before access is granted to a resource or an action (e.g.,
read/write) is allowed.
These criteria are configured by the enterprise and should be
independently configured for every resource.
Access is granted or an action applied to a resource only if all the
criteria are met. A score-based TA computes a confidence level based
on values for every data source and enterprise-configured weights.
If the score is greater than the configured threshold value for the
resource, access is granted, or the action is performed.
Depending on how the ZTA is deployed, this may involve sending
authentication results and connection configuration information to
gateways and agents or resource portals.
Otherwise, the request is denied, or access privileges are reduced (e.g., read
access is granted but not write access for a file).

b. Singular versus Contextual:
A singular TA treats each request individually and does not take the
subject history into consideration when making its evaluation.
This can allow faster evaluations, but there is a risk that an attack
can go undetected if it stays within a subject’s allowed role.
A contextual TA takes the subject or network agent’s recent history
into consideration when evaluating access requests.
This means the PE must maintain some state information on all
subjects and applications but may be more likely to detect an attacker
using subverted credentials to access information in a pattern that is
atypical of what the PE sees for the given subject.
This also means that the PE must be informed of user behaviour by
the PA (and PEPs) that subjects interact with when communicating.
Analysis of subject behaviour can be used to provide a model of
acceptable use, and deviations from this behaviour could trigger
additional authentication checks or resource request denials

 The two factors are not always dependent on each other.
 It is possible to have a TA that assigns a confidence level to every
subject and/or device and still considers every access request
independently (i.e., singular).
 However, contextual, score-based TAs would provide the ability to
offer more dynamic and granular access control, since the score
provides a current confidence level for the requesting account and
adapts to changing factors more quickly than static policies
modified by human administrators.
 Ideally, a ZTA trust algorithm should be contextual, but this may
not always be possible with the infrastructure components
available to the enterprise.
 A contextual TA can mitigate threats where an attacker stays
close to a “normal” set of access requests for a compromised
subject account or insider attack.

 It is important to balance security, usability, and cost-effectiveness when
defining and implementing trust algorithms.
 Continually prompting a subject for reauthentication against behaviour that
is consistent with historical trends and norms for their mission function and
role within the organization can lead to usability issues.
 For example, if an employee in the HR department of an agency normally
accesses 20 to 30 employee records in a typical workday, a contextual TA may
send an alert if the access requests suddenly exceed 100 records in a day.
 A contextual TA may also send an alert if someone is making access requests
after normal business hours as this could be an attacker exfiltrating records
by using a compromised HR account.
 These are examples where a contextual TA can detect an attack whereas a
singular TA may fail to detect the new behaviour.
 In another example, an accountant who typically accesses the financial
system during normal business hours is now trying to access the system in the
middle of the night from an unrecognizable location.
 A contextual TA may trigger an alert and require the subject to satisfy a more
stringent confidence level or other criteria as outlined in NIST Special
Publication 800-63A [SP800-63A].

 Developing a set of criteria or weights/threshold values for each resource
requires planning and testing.
 Enterprise administrators may encounter issues during the initial
implementation of ZTA where access requests that should be approved are
denied due to misconfiguration.
 This will result in an initial “tuning” phase of deployment.
 Criteria or scoring weights may need to be adjusted to ensure that the policies
are enforced while still allowing the enterprise’s business processes to
function.
 How long this tuning phase lasts depends on the enterprise-defined metrics
for progress and tolerance for incorrect access denials/approvals for the
resources used in the workflow.

 In a ZT environment, there should be a separation (logical or possibly
physical) of the communication flows used to control and configure the
network and application/service communication flows used to perform
the actual work of the organization.
 This is often broken down to a control plane for network control
communication and a data plane for application/service communication
flows [Gilman].
 The control plane is used by various infrastructure components (both
enterprise-owned and from service providers) to maintain and configure
assets; judge, grant, or deny access to resources; and perform any
necessary operations to set up communication paths between resources.
 The data plane is used for actual communication between software
components. This communication channel may not be possible before
the path has been established via the control plane.
 For example, the control plane could be used by the PA and PEP to set
up the communication path between the subject and the enterprise
resource.
 The application/service workload would then use the data plane path
that was established.

1. Network Requirements to Support ZTA
1. Enterprise assets have basic network connectivity.
The local area network (LAN), enterprise controlled or not, provides basic routing
and infrastructure (e.g., DNS).
The remote enterprise asset may not necessarily use all infrastructure services.
2. The enterprise must be able to distinguish between what assets are owned
or managed by the enterprise and the devices’ current security posture.
This is determined by enterprise-issued credentials and not using information
that cannot be authenticated information (e.g., network MAC addresses that can
be spoofed).
3. The enterprise can observe all network traffic.
The enterprise records packets seen on the data plane, even if it is not
able to perform application layer inspection (i.e., OSI layer 7) on all
packets.
The enterprise filters out metadata about the connection (e.g.,
destination, time, device identity) to dynamically update policies and
inform the PE as it evaluates access requests.

4. Enterprise resources should not be reachable without accessing a
PEP.
Enterprise resources do not accept arbitrary incoming connections
from the internet.
Resources accept custom-configured connections only after a client
has been authenticated and authorized.
These communication paths are set up by the PEP. Resources may
not even be discoverable without accessing a PEP.
This prevents attackers from identifying targets via scanning
and/or launching DoS attacks against resources located behind
PEPs.
Note that not all resources should be hidden this way; some
network infrastructure components (e.g., DNS servers) must be
accessible. .

5. The data plane and control plane are logically separate.
The policy engine, policy administrator, and PEPs communicate on
a network that is logically separate and not directly accessible by
enterprise assets and resources. The data plane is used for
application/service data traffic.
The policy engine, policy administrator, and PEPs use the control
plane to communicate and manage communication paths between
assets.
The PEPs must be able to send and receive messages from both the
data and control planes.

6. Enterprise assets can reach the PEP component.
Enterprise subjects must be able to access the PEP component to
gain access to resources.
This could take the form of a web portal, network device, or
software agent on the enterprise asset that enables the connection.
7. The PEP is the only component that accesses the policy administrator
as part of a business flow.
Each PEP operating on the enterprise network has a connection to
the policy administrator to establish communication paths from
clients to resources.
All enterprise business process traffic passes through one or more
PEPs.

8. Remote enterprise assets should be able to access enterprise
resources without needing to traverse enterprise network
infrastructure first.
For example, a remote subject should not be required to use a link
back to the enterprise network (i.e., virtual private network [VPN])
to access services utilized by the enterprise and hosted by a public
cloud provider (e.g., email).
9. The infrastructure used to support the ZTA access decision process
should be made scalable to account for changes in process load.
The PE(s), PA(s), and PEPs used in a ZTA become the key
components in any business process.
Delay or inability to reach a PEP (or inability of the PEPs to reach
the PA/PE) negatively impacts the ability to perform the workflow.
An enterprise implementing a ZTA needs to provision the
components for the expected workload or be able to rapidly scale the
infrastructure to handle increased usage when needed.

10. Enterprise assets may not be able to reach certain PEPs due to policy
or observable factors.
For example, there may be a policy stating that mobile assets may
not be able to reach certain resources if the requesting asset is
located outside of the enterprise’s home country.
These factors could be based on location (geolocation or network
location), device type, or other criteria.

Any enterprise environment can be designed with zero trust tenets
in mind.
Most organizations already have some elements of zero trust in
their enterprise infrastructure or are on their way through
implementation of information security and resiliency policies and
best practices.
Several deployment scenarios and use cases lend themselves
readily to a zero trust architecture.
For instance, ZTA has its roots in organizations that are
geographically distributed and/or have a highly mobile workforce.
That said, any organization can benefit from a zero trust
architecture.
In the use cases below, ZTA is not explicitly indicated since the
enterprise likely has both perimeter-based and possibly ZTA
infrastructures.
There will likely be a period when ZTA components and perimeter-
based network infrastructure are concurrently in operation in an

1. Enterprise with Satellite Facilities.
The most common scenario involves an enterprise with a single
headquarters and one or more geographically dispersed locations that
are not joined by an enterprise-owned physical network connection
(see Figure below).
Employees at the remote location may not have a full enterprise
owned local network but still need to access enterprise resources to
perform their tasks.
The enterprise may have a Multiprotocol Label Switch (MPLS) link to
the enterprise HQ network but may not have adequate bandwidth for
all traffic or may not wish for traffic destined for cloud based
applications/services to traverse through the enterprise HQ network.
Likewise, employees may be teleworking or in a remote location and
using enterprise-owned or personally-owned devices.
In such cases, an enterprise may wish to grant access to some
resources (e.g., employee calendar, email) but deny access or restrict
actions to more sensitive resources (e.g., HR database).

Enterprise with Remote Employees

1. Enterprise with Satellite Facilities.
In this use case, the PE/PA(s) is often hosted as a cloud service (which
usually provides superior availability and would not require remote
workers to rely on enterprise infrastructure to access cloud resources)
with end assets having an installed agent or accessing a resource
portal.
It may not be most responsive to have the PE/PA(s) hosted on the
enterprise local network as remote offices and workers must send all
traffic back to the enterprise network to reach applications/services
hosted by cloud services.

2. Multi-cloud/Cloud-to-Cloud Enterprise
One increasingly common use case for deploying a ZTA is an
enterprise utilizing multiple cloud providers (see Figure below).
In this use case, the enterprise has a local network but uses two or
more cloud service providers to host applications/services and data.
 Sometimes, the application/service is hosted on a cloud service that
is separate from the data source.
For performance and ease of management, the application hosted in
Cloud Provider A should be able to connect directly to the data source
hosted in Cloud Provider B rather than force the application to tunnel
back through the enterprise network

2. Multi-cloud/Cloud-to-Cloud Enterprise
This use case is the server-server implementation of the CSA’s software
defined perimeter (SDP) specification [CSA-SDP].
As enterprises move to more cloud-hosted applications and services, it
becomes apparent that relying on the enterprise perimeter for security
becomes a liability.
ZT principles take the view that there should be no difference between
enterprise-owned and -operated network infrastructure and infrastructure
owned and operated by any other service provider.
The zero trust approach to multi-cloud use is to place PEPs at the access
points of each application/service and data source.
The PE and PA may be services located in either cloud or even on a third
cloud provider.
The client (via a portal or local installed agent) then accesses the PEPs
directly. That way, the enterprise can still manage access to resources even
when hosted outside the enterprise.
One challenge is that different cloud providers have unique ways of
implementing similar functionality.
Enterprise architects will need to be aware of the how to implement their
enterprise ZTA with each cloud provider they utilize.

3. Enterprise with Contracted Services and/or Non-Employee
Access
Another common scenario is an enterprise that includes on-site
visitors and/or contracted service providers that require limited
access to enterprise resources to do their work (see Figure below).
For example, an enterprise has its own internal applications/services,
databases, and assets.
These include services contracted out to providers who may
occasionally be on-site to provide maintenance (e.g., smart heating
and lighting systems that are owned and managed by external
providers).
These visitors and service providers will need network connectivity to
perform their tasks.
A zero trust enterprise could facilitate this by allowing these devices
and any visiting service technician access to the internet while
obscuring enterprise resources.

Enterprise with Non-Employee Access

3. Enterprise with Contracted Services and/or Non-Employee
Access
In this example, the organization also has a conference centre where
visitors interact with employees. Again, with a ZTA approach of SDPs,
employee devices and subjects are differentiated and may be able to
access appropriate enterprise resources. Visitors to the campus can
have internet access but cannot access enterprise resources. They
may not even be able to discover enterprise services via network
scans (i.e., prevent active network reconnaissance/east-west
movement). In this use case, the PE(s) and PA(s) could be hosted as a
cloud service or on the LAN (assuming little or no use of cloud-hosted
services). The enterprise assets could have an installed agent (see
Section 3.2.1) or access resources via a portal (see Section 3.2.3). The
PA(s) ensures that all non-enterprise assets (those that do not have
installed agents or cannot connect to a portal) cannot access local
resources but may access the internet.

4. Collaboration Across Enterprise Boundaries
A fourth use case is cross-enterprise collaboration.
For example, there is a project involving employees from Enterprise A
and Enterprise B (see Figure - Cross-Enterprise Collaboration).
The two enterprises may be separate federal agencies (G2G) or even a
federal agency and a private enterprise (G2B).
Enterprise A operates the database used for the project but must
allow access to the data for certain members of Enterprise B.
Enterprise A can set up specialized accounts for the employees of
Enterprise B to access the required data and deny access to all other
resources, but this can quickly become difficult to manage.
Having both organizations enrolled in a federated ID management
system would allow quicker establishment of these relationships
provided that both organizations’ PEPs can authenticate subjects in a
federated ID community.

Cross-Enterprise Collaboration

4. Collaboration Across Enterprise Boundaries
This scenario can be similar to Use Case 1 as employees of both
enterprises may not be located on their organizations’ network
infrastructures, and the resource they need to access may be within
one enterprise environment or hosted in the cloud.
This means that there do not need to be complex firewall rules or
enterprise-wide access control lists (ACLs) allowing certain IP
addresses belonging to Enterprise B to access resources in Enterprise
A based on Enterprise A’s access policies.
How this access is accomplished depends on the technology in use.
Similar to Use Case 1, a PE and PA hosted as a cloud service may
provide availability to all parties without having to establish a VPN
or similar.
The employees of Enterprise B may be asked to install a software
agent on their asset or access the necessary data resources through a
web gateway.

5. Enterprise with Public- or Customer-Facing Services
A common feature in many enterprises is a public-facing service that
may or may not include user registration (i.e., users must create or
have been issued a set of login credentials).
Such services could be for the general public, a set of customers with
an existing business relationship, or a special set of non-enterprise
users such as employee dependents.
In all cases, it is likely that requesting assets are not enterprise-
owned, and the enterprise is constrained as to what internal
cybersecurity polices can be enforced.
For a general, public-facing resource that does not require login
credentials to access (e.g., public web page), the tenets of ZTA do not
directly apply.
The enterprise cannot strictly control the state of requesting assets,
and anonymous public resources (e.g., a public web page) do not
require credentials in order to be accessed.

5. Enterprise with Public- or Customer-Facing Services
Enterprises may establish policies for registered public users such as
customers (i.e., those with a business relationship) and special users (e.g.,
employee dependents).
If the users are required to produce or are issued credentials, the enterprise
may institute policies regarding password length, life cycle, and other
details and may provide MFA as an option or requirement.
However, enterprises are limited in the policies they can implement for this
class of user.
Information about incoming requests may be useful in determining the
state of the public service and detecting possible attacks masquerading as
legitimate users.
For example, a registered user portal is known to be accessed by registered
customers using one of a set of common web browsers.
A sudden increase in access requests from unknown browser types or known
outdated versions could indicate an automated attack of some kind, and the
enterprise could take steps to limit requests from these identified clients.
The enterprise should also be aware of any statutes or regulations
regarding what information can be collected and recorded about the
requesting users and assets.

No enterprise can eliminate cybersecurity risk.
When complemented with existing cybersecurity
policies and guidance, identity and access
management, continuous monitoring, and general
cyber hygiene, a properly implemented and
maintained ZTA can reduce overall risk and protect
against common threats.
However, some threats have unique features when
implementing a ZTA.

1. Subversion of ZTA Decision Process
In ZTA, the policy engine and policy administrator are the key components of the
entire enterprise.
No communication between enterprise resources occurs unless it is approved and
possibly configured by the PE and PA.
This means that these components must be properly configured and maintained.
Any enterprise administrator with configuration access to the PE’s rules may be
able to perform unapproved changes or make mistakes that can disrupt enterprise
operations. Likewise, a compromised PA could allow access to resources that would
otherwise not be approved (e.g., to a subverted, personally-owned device).
Mitigating associated risks means the PE and PA components must be properly
configured and monitored, and any configuration changes must be logged and
subject to audit.

2. Denial-of-Service or Network Disruption
In ZTA, the PA is the key component for resource access.
Enterprise resources cannot connect to each other without the PA’s permission and,
possibly, configuration action.
If an attacker disrupts or denies access to the PEP(s) or PE/PA (i.e., DoS attack or
route hijack), it can adversely impact enterprise operations.
Enterprises can mitigate this threat by having the policy enforcement reside in a
properly secured cloud environment or be replicated in several locations following
guidance on cyber resiliency [SP 800-160v2].
This mitigates the risk but does not eliminate it. Botnets such as Mirai produce
massive DoS attacks against key internet service providers and disrupt service to
millions of internet users.
It is also possible that an attacker could intercept and block traffic to a PEP or PA
from a portion or all of the user accounts within an enterprise (e.g., a branch office
or even a single remote employee). In such cases, only a portion of enterprise
subjects is affected. This is also possible in legacy remote-access VPNs and is not
unique to ZTA.

2. Denial-of-Service or Network Disruption
A hosting provider may also accidentally take a cloud-based PE or PA offline.
Cloud services have experienced disruptions in the past, both infrastructure as a
service (IaaS) and SaaS.
An operational error could prevent an entire enterprise from functioning if the
policy engine or policy administrator component becomes inaccessible from the
network.
There is also the risk that enterprise resources may not be reachable from the PA,
so even if access is granted to a subject, the PA cannot configure the communication
path from the network. This could happen due to a DDoS attack or simply due to
unexpected heavy usage.
This is similar to any other network disruption in that some or all enterprise
subjects cannot access a particular resource due to that resource not being available
for some reason.

3. Stolen Credentials/Insider Threat
Properly implemented ZT, information security and resiliency policies, and best
practices reduce the risk of an attacker gaining broad access via stolen credentials or
insider attack.
The ZT principle of no implicit trust based on network location means attackers need to
compromise an existing account or device to gain a foothold in an enterprise.
A properly developed and implemented ZTA should prevent a compromised account or
asset from accessing resources outside its normal purview or access patterns.
This means that accounts with access policies around resources that an attacker is
interested in would be the primary targets for attackers.
Attackers may use phishing, social engineering, or a combination of attacks to obtain
credentials of valuable accounts.
“Valuable” may mean different things based on the attacker’s motivation.
For instance, enterprise administrator accounts may be valuable, but attackers
interested in financial gain may consider accounts that have access to financial or
payment resources of equal value.
Implementation of MFA for access requests may reduce the risk of information loss from
a compromised account.

3. Stolen Credentials/Insider Threat
However, an attacker with valid credentials (or a malicious insider) may still be
able to access resources for which the account has been granted access. For
example, an attacker or compromised employee who has the credentials and
enterprise-owned asset of a valid human resources employee may still be able to
access an employee database.
ZTA reduces risk and prevents any compromised accounts or assets from moving
laterally throughout the network. If the compromised credentials are not
authorized to access a particular resource, they will continue to be denied access to
that resource. In addition, a contextual trust algorithm (see Section 3.3.1) is more
likely to detect and respond quickly to this attack than when occurring in a legacy,
perimeter-based network. The contextual TA can detect access patterns that are out
of normal behaviour and deny the compromised account or insider threat

4. Visibility on the Network
All traffic is inspected and logged on the network and analysed to identify and react to
potential attacks against the enterprise.
However, as also mentioned, some (possibly the majority) of the traffic on the enterprise
network may be opaque to layer 3 network analysis tools.
This traffic may originate from non-enterprise-owned assets (e.g., contracted services
that use the enterprise infrastructure to access the internet) or applications/services
that are resistant to passive monitoring.
The enterprise that cannot perform deep packet inspection or examine the encrypted
traffic and must use other methods to assess a possible attacker on the network.
That does not mean that the enterprise is unable to analyse encrypted traffic that it
sees on the network.
The enterprise can collect metadata (e.g., source and destination addresses, etc.) about
the encrypted traffic and use that to detect an active attacker or possible malware
communicating on the network.
Machine learning techniques [Anderson] can be used to analyse traffic that cannot be
decrypted and examined. Employing this type of machine learning would allow the
enterprise to categorize traffic as valid or possibly malicious and subject to remediation.

5. Storage of System and Network Information
A related threat to enterprise monitoring and analysis of network traffic is the analysis
component itself.
If monitor scans, network traffic, and metadata are being stored for building contextual
policies, forensics, or later analysis, that data becomes a target for attackers.
Just like network diagrams, configuration files, and other assorted network architecture
documents, these resources should be protected.
If an attacker can successfully gain access to this information, they may be able to gain
insight into the enterprise architecture and identify assets for further reconnaissance
and attack.
Another source of reconnaissance information for an attacker in a ZT enterprise is the
management tool used to encode access policies.
Like stored traffic, this component contains access policies to resources and can give an
attacker information on which accounts are most valuable to compromise (e.g., the ones
that have access to the desired data resources).
As for all valuable enterprise data, adequate protections should be in place to prevent
unauthorized access and access attempts.
As these resources are vital to security, they should have the most restrictive access
policies and be accessible only from designated or dedicated administrator accounts.

6. Reliance on Proprietary Data Formats or Solutions
ZTA relies on several different data sources to make access decisions, including
information about the requesting subject, asset used, enterprise and external
intelligence, and threat analysis.
Often, the assets used to store and process this information do not have a common,
open standard on how to interact and exchange information.
This can lead to instances where an enterprise is locked into a subset of providers
due to interoperability issues.
If one provider has a security issue or disruption, an enterprise may not be able to
migrate to a new provider without extreme cost (e.g., replacing several assets) or
going through a long transition program (e.g., translating policy rules from one
proprietary format to another).
Like DoS attacks, this risk is not unique to ZTA, but because ZTA is heavily
dependent on the dynamic access of information (both enterprise and service
providers), disruption can affect the core business functions of an enterprise.
To mitigate associated risks, enterprises should evaluate service providers on a
holistic basis by considering factors such as vendor security controls, enterprise
switching costs, and supply chain risk management in addition to more typical
factors such as performance, stability, etc.

7. Use of Non-person Entities (NPE) in ZTA Administration
 Artificial intelligence and other software-based agents are being deployed to manage security
issues on enterprise networks.
 These components need to interact with the management components of ZTA (e.g., policy engine,
policy administrator), sometimes in lieu of a human administrator.
 How these components authenticate themselves in an enterprise implementing a ZTA is an open
issue. It is assumed that most automated technology systems will use some means to authenticate
when using an API to resource components.
 The biggest risk when using automated technology for configuration and policy enforcement is the
possibility of false positives (innocuous actions mistaken for attacks) and false negatives (attacks
mistaken for normal activity) impacting the security posture of the enterprise.
 This can be reduced with regular retuning analysis to correct mistaken decisions and improve the
decision process.
 The associated risk is that an attacker will be able to induce or coerce an NPE to perform some
task that the attacker is not privileged to perform.
 The software agent may have a lower bar for authentication (e.g., API key versus MFA) to perform
administrative or security-related tasks compared with a human user.
 If an attacker can interact with the agent, they could theoretically trick the agent into allowing
the attacker greater access or into performing some task on behalf of the attacker.
 There is also a risk that an attacker could gain access to a software agent’s credentials and
impersonate the agent when performing tasks.

Several existing federal policies and guidance intersect with the
planning, deployment, and operation of a ZTA. These policies do
not prohibit an enterprise from moving to a more zero trust-
oriented architecture but can influence development of a zero
trust strategy for an agency. When complemented with existing
cybersecurity policies and guidance, ICAM, continuous
monitoring, and general cyber hygiene, ZTA may reinforce an
organization’s security posture and protect against common
threats.

Implementing a ZTA is a journey rather than a wholesale replacement of infrastructure or
processes.
An organization should seek to incrementally implement zero trust principles, process changes,
and technology solutions that protect its highest value data assets.
Most enterprises will continue to operate in a hybrid zero-trust/perimeter-based mode for an
indefinite period while continuing to invest in ongoing IT modernization initiatives.
Having an IT modernization plan that includes moving to an architecture based on ZT principles
may help an enterprise form roadmaps for small scale workflow migrations.
How an enterprise migrates to a strategy depends on its current cybersecurity posture and
operations.
An enterprise should reach a baseline of competence before it becomes possible to deploy a
significant ZT-focused environment [ACT-IAC].
This baseline includes having assets, subjects, business processes, traffic flows and dependency
mappings identified and catalogued for the enterprise.
The enterprise needs this information before it can develop a list of candidate business processes
and the subjects/assets involved in this process.

1. Pure Zero Trust Architecture
 In a greenfield approach, it would be possible to build a zero trust architecture from the ground up.
 Assuming the enterprise knows the applications/services and workflows that it wants to use for its
operations, it can produce an architecture based on zero trust tenets for those workflows.
 Once the workflows are identified, the enterprise can narrow down the components needed and begin to
map how the individual components interact.
 From that point, it is an engineering and organizational exercise in building the infrastructure and
configuring the components.
 This may include additional organizational changes depending on how the enterprise is currently set up
and operating.
 In practice, this is rarely a viable option for federal agencies or any organization with an existing
network.
 However, there may be times when an organization is asked to fulfil a new responsibility that would
require building its own infrastructure.
 In these cases, it might be possible to introduce ZT concepts to some degree.
 For example, an agency may be given a new responsibility that entails building a new application,
service, or database.
 The agency could design the newly needed infrastructure around ZT principles and secure system
engineering [SP8900-160v1], such as evaluating subjects’ trust before granting access and establishing
micro-perimeters around new resources.
 The degree of success depends on how dependent this new infrastructure is on existing resources (e.g.,
ID management systems).

2. Hybrid ZTA and Perimeter-Based Architecture
It is unlikely that any significant enterprise can migrate to zero trust in a single
technology refresh cycle.
There may be an indefinite period when ZTA workflows coexist with non-ZTA
workflows in an enterprise.
Migration to a ZTA approach to the enterprise may take place one business
process at a time. The enterprise needs to make sure that the common elements
(e.g., ID management, device management, event logging) are flexible enough to
operate in a ZTA and perimeter-based hybrid security architecture. Enterprise
architects may also want to restrict ZTA candidate solutions to those that can
interface with existing components.
Migrating an existing workflow to a ZTA will likely require (at least) a partial
redesign.
Enterprises may take this opportunity to adopt secure system engineering
[SP800-160v1] practices if they have not already done so for workflows.

3. Steps to Introducing ZTA to a Perimeter-Based Architected
Network
Migrating to ZTA requires an organization to have detailed knowledge of
its assets (physical and virtual), subjects (including user privileges), and
business processes.
This knowledge is accessed by the PE when evaluating resource requests.
Incomplete knowledge will most often lead to a business process failure
where the PE denies requests due to insufficient information.
This is especially an issue if there are unknown “shadow IT” deployments
operating within an organization.

Network
Before undertaking an effort to bring ZTA to an enterprise, there should
be a survey of assets, subjects, data flows, and workflows.
This awareness forms the foundational state that must be reached before
a ZTA deployment is possible.
An enterprise cannot determine what new processes or systems need to
be in place if there is no knowledge of the current state of operations.
These surveys can be conducted in parallel, but both are tied to
examination of the business processes of the organization.
These steps can be mapped to the steps in the RMF [SP800-37] as any
adoption of a ZTA is a process to reduce risk to an agency’s business
functions. The pathway to implementing a ZTA can be visualized in
Figure – ZTA Deployment Cycle.

Network
After the initial inventory is created, there is a regular cycle of
maintenance and updating.
This updating may either change business processes or not have any
impact, but an evaluation of business processes should be conducted.
For example, a change in digital certificate providers may not appear to
have a significant impact but may involve certificate root store
management,
Certificate Transparency log monitoring, and other factors that are not
apparent at first.

3. Steps to Introducing ZTA to a Perimeter-Based Architected Network
i. Identify Actors on the Enterprise
For a zero trust enterprise to operate, the PE must have knowledge of
enterprise subjects.
Subjects could encompass both human and possible NPEs, such as service
accounts that interact with resources.
Users with special privileges, such as developers or system administrators,
require additional scrutiny when being assigned attributes or roles.
In many legacy security architectures, these accounts may have blanket
permission to access all enterprise resources.
ZTA should allow developers and administrators to have sufficient flexibility to
satisfy their business requirements while using logs and audit actions to
identify access behaviour patterns.
ZTA deployments may require administrators to satisfy a more stringent
confidence level or criteria as outlined in NIST SP 800-63A, Section 5 [SP800-
63A].

ii. Identify Assets Owned by the Enterprise
One of the key requirements of ZTA is the ability to identify and manage
devices.
ZTA also requires the ability to identify and monitor non-enterprise-owned
devices that may be on enterprise-owned network infrastructure or that access
enterprise resources.
The ability to manage enterprise assets is key to the successful deployment of
ZTA.
This includes hardware components (e.g., laptops, phones, IoT devices) and
digital artifacts (e.g., user accounts, applications, digital certificates).
It may not be possible to conduct a complete census on all enterprise-owned
assets, so an enterprise should consider building the capability to quickly
identify, categorize, and assess newly discovered assets that are on enterprise-
owned infrastructure.

Network
This goes beyond simply cataloguing and maintaining a database of
enterprise assets.
This also includes configuration management and monitoring.
The ability to observe the current state of an asset is part of the process
of evaluating access requests.
This means that the enterprise must be able to configure, survey, and
update enterprise assets, such as virtual assets and containers.
This also includes both its physical (as best estimated) and network
location.
This information should inform the PE when making resource access
decisions..

Network
Non-enterprise-owned assets and enterprise-owned “shadow IT” should
also be catalogued as well as possible.
This may include whatever is visible by the enterprise (e.g., MAC
address, network location) and augmented by administrator data entry.
This information is not only used for access decisions (as collaborator
and BYOD assets may need to contact PEPs) but also for monitoring and
forensics logging by the enterprise.
Shadow IT presents a special problem in that these resources are
enterprise-owned but not managed like other resources.
Certain ZTA approaches (mainly network-based) may even cause shadow
IT components to become unusable as they may not be known and
included in network access policies.

Network
iii. Identify Key Processes and Evaluate Risks Associated with
Executing Process
The third inventory that an agency should undertake is to identify and
rank the business processes, data flows, and their relation in the
missions of the agency.
Business processes should inform the circumstances under which
resource access requests are granted and denied.
An enterprise may wish to start with a low-risk business process for the
first transition to ZTA as disruptions will likely not negatively impact the
entire organization.
Once enough experience is gained, more critical business processes can
become candidates.

Network
iii. Identify Key Processes and Evaluate Risks Associated with
Executing Process
Business processes that utilize cloud-based resources or are used by
remote workers are often good candidates for ZTA and would likely see
improvements to availability and security.
Rather than project the enterprise perimeter into the cloud or bring
clients into the enterprise network via a VPN, enterprise clients can
request cloud services directly.
The enterprise’s PEPs ensure that enterprise policies are followed before
resource access is granted to a client.
Planners should also consider potential trade-offs in performance, user
experience, and possible increased workflow fragility that may occur
when implementing ZTA for a given business process.

iv. Formulating Policies for the ZTA Candidate
The process of identifying a candidate service or business workflow depends on several
factors:
the importance of the process to the organization,
the group of subjects affected, and
the current state of resources used for the workflow.
The value of the asset or workflow based on risk to the asset or workflow can be
evaluated using the NIST Risk Management Framework [SP800-37].
After the asset or workflow is identified, identify all upstream resources (e.g., ID
management systems, databases, micro-services), downstream resources (e.g., logging,
security monitoring), and entities (e.g., subjects, service accounts) that are used or
affected by the workflow.
This may influence the candidate choice as a first migration to ZTA.
An application/service used by an identified subset of enterprise subjects (e.g., a
purchasing system) may be preferred over one that is vital to the entire subject base of
the enterprise (e.g., email).

Network
iv. Formulating Policies for the ZTA Candidate
The enterprise administrators then need to determine the set of criteria
(if using a criteria-based TA) or confidence level weights (if using a score-
based TA) for the resources used in the candidate business process.
Administrators may need to adjust these criteria or values during the
tuning phase.
These adjustments are necessary to ensure that policies are effective but
do not hinder access to resources.

Network
v. Identifying Candidate Solutions
Once a list of candidate business processes has been developed,
enterprise architects can compose a list of candidate solutions.
Some deployment models are better suited to particular workflows and
current enterprise ecosystems.
Likewise, some vendor solutions are better suited to some use cases than
others.
These are some factors to consider:
Does the solution require that components be installed on the client asset?
• This may limit business processes where non-enterprise-owned assets are used or
desired, such as BYOD or cross-agency collaborations.

Network
Does the solution work where the business process resources exist entirely on
enterprise premises?
• Some solutions assume that requested resources will reside in the cloud (so-called
north-south traffic) and not within an enterprise perimeter (east-west traffic). The
location of candidate business process resources will influence candidate solutions
as well as the ZTA for the process.
Does the solution provide a means to log interactions for analysis?
• A key component of ZT is the collection and use of data related to the process flow
that feeds back into the PE when making access decisions.

Does the solution provide broad support for different applications, services, and protocols?
• Some solutions may support a broad range of protocols (web, secure shell [SSH], etc.)
and transports (IPv4 and IPv6), while others may only work with a narrow focus such
as web or email.
Does the solution require changes to subject behaviour?
• Some solutions may require additional steps to perform a given workflow. This may
change how enterprise subjects perform the workflow.
One solution is to model an existing business process as a pilot program rather than
just a replacement. This pilot program could be made general to apply to several
business processes or be made specific to one use case. The pilot can be used as a
“proving ground” for ZTA before transitioning subjects to the ZTA deployment and away
from the legacy process infrastructure.

Network
vi. Initial Deployment and Monitoring
Once the candidate workflow and ZTA components are chosen, the initial
deployment can start.
Enterprise administrators must implement the developed policies by
using the selected components but may wish to operate in an observation
and monitoring mode at first.
Few enterprise policy sets are complete in their first iterations:
important user accounts (e.g., administrator accounts) may be denied
access to resources they need or may not need all the access privileges
they have been assigned.

Network
The new ZT business workflow could be operated in reporting-only mode
for some time to make sure the policies are effective and workable.
This also allows the enterprise to gain an understanding of baseline
asset and resource access requests, behaviour, and communication
patterns.
Reporting-only means that access should be granted for most requests,
and logs and traces of connections should be compared with the initial
developed policy.
Basic policies such as denying requests that fail MFA or appear from
known, attacker controlled or subverted IP addresses should be enforced
and logged, but after initial deployment, access polices should be more
lenient to collect data from actual interactions of the ZT workflow.

Network
Once the baseline activity patterns for the workflow has been
established, anomalous behaviour can be more easily identify.
If it is not possible to operate in a more lenient nature, enterprise
network operators should monitor logs closely and be prepared to modify
access policies based on operational experience.

Network
vii. Expanding the ZTA
When enough confidence is gained and the workflow policy set is refined,
the enterprise enters the steady operational phase.
The network and assets are still monitored, and traffic is logged, but
responses and policy modifications are done at a lower tempo as they
should not be severe.
The subjects and stakeholders of the resources and processes involved
should also provide feedback to improve operations.
At this stage, the enterprise administrators can begin planning the next
phase of ZT deployment.
Like the previous rollout, a candidate workflow and solution set need to
be identified and initial policies developed.

Network
vii. Expanding the ZTA
However, if a change occurs to the workflow, the operating ZT
architecture needs to be re-evaluated.
Significate changes to the system—such as new devices, major updates
to software (especially ZT logical components), and shifts in
organizational structure—may result in changes to the workflow or
policies.
In effect, the entire process should be reconsidered with the assumption
that some of the work has already been done.
For example, new devices have been purchased, but no new user
accounts have been created, so only the device inventory needs to be
updated.

The current maturity of zero trust components and solutions was
surveyed during the research conducted in the development of this
document.
This survey concluded that the current state of the ZTA ecosystem is not
mature enough for widespread adoption. While it is possible to use ZTA
strategies to plan and deploy an enterprise environment, there is no
single solution that provides all the necessary components.
Also, few ZTA components available today can be used for all of the
various workflows present in an enterprise.
The following is a summary of identified gaps in the ZTA ecosystem and
areas that need further investigation.
Some of these areas have some foundation of work, but how ZTA tenets
change these areas is not well-known as there is not enough experience
with diverse ZTA-focused enterprise environments.

1. Technology Survey
Multiple vendors were invited to present their products
and views on zero trust.
The goal of this survey was to identify missing pieces that
prevent agencies from moving to a zero trust based
enterprise infrastructure now or maintaining an existing
ZTA implementation.
These gaps can be categorized into immediate deployment
(immediate or short term), systemic gaps that affect
maintenance or operations (short or midterm), and missing
knowledge (areas for future research). They are
summarized in Table - Summary of Identified Deployment
Gaps.

Summary of Identified Deployment Gaps

2. Gaps that Prevent an Immediate Move to ZTA
These are the issues that are slowing adoption of a ZTA at
present.
These were classified as immediate issues, and no thought
of future maintenance or migration was considered for this
category.
A forward-thinking enterprise may also consider the
maintenance category to be of immediate concern in
preventing the initial deployment of ZTA components, but
these issues are considered a separate category for this
analysis..

i. Lack of Common Terms for ZTA Design, Planning, and Procurement
 Zero trust as a strategy for the design and deployment of enterprise
infrastructure is still a forming concept.
 Industry has not yet coalesced around a single set of terms or concepts to
describe ZTA components and operations.
 This makes it difficult for organizations to develop coherent requirements and
policies for designing zero trust enterprise infrastructure and procuring
components.
 The driver is an initial attempt to form a neutral base of terms and concepts to
describe ZTA.
 The abstract ZTA components and deployment models were developed to serve
as basic terms and ways to think about ZTA.
 The goal is to provide a common way to view, model, and discuss ZTA solutions
when developing enterprise requirements and performing market surveys.
 The above sections may prove to be incomplete as more experience is gained
with ZTA in federal agencies, but they currently serve as a base for a common
conceptual framework.

ii. Perception that ZTA Conflicts with Existing Federal Cybersecurity
Policies
 There is a misconception that ZTA is a single framework with a set of
solutions that are incompatible with the existing view of cybersecurity.
 Zero trust should instead be viewed as an evolution of current cybersecurity
strategies as many of the concepts and ideas have been circulating for a long
time.
 Federal agencies have been encouraged to take a more zero trust approach
to cybersecurity through existing guidance.
 If an agency has a mature ID management system and robust CDM
capabilities in place, it is on the road to a ZTA.
 This gap is based on a misconception of ZTA and how it has evolved from
previous cybersecurity paradigms

iii. Systemic Gaps that Impact ZTA
 These are the gaps that affect initial implementation and deployment of ZTA
and continued operation/maturity.
 These gaps could slow the adoption of ZTA in agencies or result in
fragmentation of the ZTA component industry.
 Systemic gaps are areas where open standards (produced either by a
standards development organization [SDO] or industry consortium) can
help.

a) Standardization of Interfaces Between Components
 During the technology survey, it became apparent that no one vendor offers a
single solution that will provide zero trust.
 Furthermore, it might not be desirable to use a single-vendor solution to achieve
zero trust and thereby risk vendor lock-in. This leads to interoperability within
components not only at the time of purchase but also over time.
 The spectrum of components within the wider enterprise is vast, with many
products focusing on a single niche within zero trust and relying on other
products to provide either data or some service to another component (e.g.,
integration of MFA for resource access).
 Vendors too often rely on proprietary APIs provided by partner companies rather
than standardized, vendor-independent APIs to achieve this integration.
 The problem with this approach is that these APIs are proprietary and single-
vendor controlled.
 The controlling vendor can change the API behaviour, and integrators are
required to update their products in response.

a) Standardization of Interfaces Between Components
 This requires close partnerships between communities of vendors to ensure early
notification of modifications within APIs, which may affect compatibility between
products.
 This adds an additional burden on vendors and consumers:
 vendors need to expend resources to change their products, and consumers need to
apply updates to multiple products when one vendor makes a change to its proprietary
API.
 Additionally, vendors are required to implement and maintain wrappers for each
partner component to allow maximum compatibility and interoperability.
 For example, many MFA product vendors are required to create a different wrapper for
each cloud provider or identity management system to be usable in different kinds of
client combinations.
 On the customer side, this generates additional problems when developing
requirements for purchasing products.
 There are no standards that purchasers can rely on to identify compatibility between
products.
 Hence, it is very difficult to create a multiyear road map for moving into ZTA because
it is impossible to identify a minimum set of compatibility requirements for
components.

a) Emerging Standards that Address Overreliance on Proprietary APIs
 As there is no single solution to developing a ZTA, there is no single set of tools
or services for a zero trust enterprise.
 Thus, it is impossible to have a single protocol or framework that enables an
enterprise to move to a ZTA.
 Currently, there is a wide variety of models and solutions seeking to become the
leading authority of ZTA.
 This indicates that there is an opportunity for a set of open, standardized
protocols or frameworks to be developed to aid organizations in migrating to a
ZTA.
 SDOs like the Internet Engineering Task Force (IETF) have specified protocols
that may be useful in exchanging threat information (called XMPP-Grid [1]).
 The Cloud Security Alliance (CSA) has produced a framework for Software
Defined Perimeter (SDP) that may also be useful in ZTA.
 Efforts should be directed toward surveying the current state of ZTA-related
frameworks or the protocols necessary for a useful ZTA and toward identifying
places where work is needed to produce or improve these specifications.

iv. Knowledge Gaps in ZTA and Future Areas of Research
The gaps listed here do not hinder an organization from adopting a ZTA for its
enterprise.
These are gray areas in knowledge about operational ZTA environments, and
most arise from a lack of time and experience with mature zero trust
deployments.
These are areas of future work for researchers.
v. Attacker Response to ZTA
A properly implemented ZTA for an enterprise will improve the enterprise’s
cybersecurity posture over traditional network perimeter-based security.
The tenets of ZTA aim to reduce the exposure of resources to attackers and
minimize or prevent lateral movement within an enterprise should a host asset
be compromised..

v. Attacker Response to ZTA
However, determined attackers will not sit idle but will instead change
behaviour in the face of ZTA.
The open issue is how the attacks will change.
One possibility is that attacks aimed at stealing credentials will be expanded to
target MFA (e.g., phishing, social engineering).
Another possibility is that in a hybrid ZTA/perimeter-based enterprise,
attackers will focus on the business processes that have not had ZTA tenets
applied (i.e., follow traditional network perimeter-based security)—in effect,
targeting the low-hanging fruit in an attempt to gain some foothold in the ZTA
business process.
As ZTA matures, more deployments are seen, and experience is gained, the
effectiveness of ZTA in shrinking the attack surface of resources may become
apparent.
The metrics of success of ZTA over older cybersecurity strategies will also need
to be developed.

vi. User Experience in a ZTA Environment
There has not been a rigorous examination of how end users act in an enterprise
that is using a ZTA.
This is mainly due to the lack of large ZTA use cases available for analysis.
There have, however, been studies on how users react to MFA and other security
operations that are part of a ZTA enterprise, and this work could form the basis of
predicting end user experience and behaviour when using ZTA workflows in an
enterprise.
One set of studies that can predict how ZTA affects end user experience is the work
done on the use of MFA in enterprises and security fatigue.
Security fatigue is the phenomenon wherein end users are confronted with so many
security policies and challenges that it begins to impact their productivity in a
negative way.
Other studies show that MFA may alter user behaviour, but the overall change is
mixed.
Some users readily accept MFA if the process is streamlined and involves devices
they are used to using or having with them (e.g., applications on a smartphone).
However, some users resent having to use personally-owned devices for business
processes or feel that they are being constantly monitored for possible violations of
IT policies.

vii. Resilience of ZTA to Enterprise and Network Disruption
The survey of the ZTA vendor ecosystem displayed the wide range of
infrastructure that an enterprise deploying a ZTA would need to consider.
As previously noted, there is no single provider of a full zero trust solution at
this time.
As a result, enterprises will purchase several different services and products,
which can lead to a web of dependencies for components.
If one vital component is disrupted or unreachable, there could be a cascade of
failures that impact one or multiple business processes.
Most products and services surveyed relied on a cloud presence to provide
robustness, but even cloud services have been known to become unreachable
through either an attack or simple error.
When this happens, key components used to make access decisions may be
unreachable or may not be able to communicate with other components.

vii. Resilience of ZTA to Enterprise and Network Disruption
For example, PE and PA components located in a cloud may be reachable
during a distributed denial-of-service (DDoS) attack but may not be able to
reach all PEPs located with resources.
Research is needed on discovering the possible choke points of ZTA deployment
models and the impact on network operations when a ZTA component is
unreachable or has limited reachability.
The continuity of operations (COOP) plans for an enterprise will likely need
revision when adopting a ZTA.
A ZTA makes many COOP factors easier as remote workers may have the same
access to resources that they had on-premises.
However, policies like MFA may also have a negative impact if users are not
properly trained or lack experience.
Users may forget or not have access to tokens and enterprise devices during an
emergency, and that will impact the speed and effectiveness of enterprise
business processes. .

ZERO TRUST ARCHITECTURE - DIGITAL TRUST FRAMEWORK

More Related Content

What's hot (20)

Similar to ZERO TRUST ARCHITECTURE - DIGITAL TRUST FRAMEWORK (20)

More from Maganathin Veeraragaloo (20)

Recently uploaded (20)

ZERO TRUST ARCHITECTURE - DIGITAL TRUST FRAMEWORK