Planning for a Zero Trust Architecture

NIST has recently published Planning for a Zero Trust Architecture: A Planning Guide for Federal Administrators, which can be useful for all enterprises looking to zero trust as their future cybersecurity strategy. The guide focuses on some of the planning activities that most organizations don't address in their strategy and implementation plan.

One anecdote that highlights a common challenge:

There is no single specific zero trust infrastructure implementation or architecture. Zero trust solutions depend on the workflow (i.e., part of the enterprise mission) being analyzed and the resources that are used in performing that workflow.

If your Zero Trust Strategy focuses on higher-level outcomes that does not address individual workflows, e.g. Smart Conference Room IOT devices communication patterns, then you are probably missing many critical use cases and probably aren't getting the benefits or outcomes of zero trust.

Zero Trust Architecture Review​

The NIST 800-207 publication provides an abstract logical architecture that can be used to map solutions and gaps upon. The abstract architecture is reproduced in Figure 1 below.

_{Figure 1: Core Zero Trust Logical Components}

In this diagram, the components are depicted by logical function and thus do not necessarily represent the composition of capabilities in operational systems. In many organizations, It is possible that multiple components may serve one logical function in a distributed manner, or a single solution may fulfill multiple logical roles. What should be immediately clear is that all organizations will have multiple Policy Engines, e.g. if you have Active Directory and Firewalls that is 2 already. With many organizations, having 50+ security tools in their cybersecurity architecture, aligning the disparate policy engines, enforcement points, and information feeds can become extremely complex and resource-intensive.

The roles are described in NIST SP 800-207, but are summarized below:

• Policy Engine (PE): The “brain” of a ZTA implementation and the components that ultimately evaluate resource access requests. The PE relies on information from the various data sources (access logs, threat intelligence, endpoint health, and network ID authentication, etc.)
• Policy Administrator (PA): The executor function of the PE. The PA’s role is to establish, maintain, and ultimately terminate sessions1 in the data plane between the subject and the resource. The PA, PE and PEP communicate on a logically (or physically) separate set of channels called the control plane. The control plane is used to establish and configure the data plane channels used to send application traffic.
• Policy Enforcement Point (PEP): The component that applications, endpoints, etc. will interact with to be granted access permission to a resource. The PEP is responsible for gathering information for the PE and following the instructions issued by the PA to establish and terminate communication sessions. All data plane communications between enterprise resources must be managed by a PEP.
• Information feeds (left and right): Sometimes called policy information points (PIPs). These are not “core” functional ZTA components themselves but used to support the PE. These feeds include the set of codified policies, identity and endpoint attributes, environmental factors and historical data used by the PE to generate resource access decisions.

Zero Trust Principles or Tenets​

_{Figure 2: ModernCyber’s Zero Trust Principles}

The NIST white paper is worth a read on its own, but here are some of the tenets that directly align to Zero Trust Principles:

• All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
• All data sources and computing services are considered resources.
• The enterprise monitors and measures the integrity and security posture of all owned and associated resources.
• All communication is secured regardless of network location.
• Access to individual enterprise resources is granted on a per-session basis. 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 behavioral and environmental attributes.
• 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.

Zero Trust Journey​

Moving to a zero trust architecture will likely never start from scratch, considering the number of security tools in use already, but will involve a series of upgrades and changes over time. Some changes may be simple configuration changes, and some may involve the purchase and deployment of new infrastructure; it all depends on what the existing security architecture and operational procedures are today vs. the proposed zero trust strategy. This is why performing a Zero Trust Maturity Assessment is one of the first recommended best practices step for a journey, even prior to strategy, architecture and implementation planning.

The process of migrating, or ""evolving"" as we like to call it, to a ZTA is not a unique process and is similar to other cybersecurity improvements but guided by zero trust principles in the planning and implementation. Existing frameworks such as the NIST Risk Management Framework (RMF) and Cybersecurity Framework (CSF) can help an enterprise discuss, develop, and implement a ZTA.

Zero Trust Operational Loops​

The NIST white paper is worth a read on its own, but the focus on operations and the need for MAJOR changes in existing feedback loops, is one of the most valuable aspects of the entire document. Determining how implementing Zero Trust will affect Cybersecurity Operations AND overall IT Operations, can be the biggest variable of whether an organization SUCCEEDS or FAILS in Zero Trust Adoption! Is it success, if implementing zero trust requires your organization to double or triple the cost of operational staff because of the policy maintenance requirements?

Zero trust lends itself to the use of more dynamic development and operations (DevOps) and DevOps and security (DevSecOps) style operations. The cycles of security updates and reviews could be described as involving a subset of the RMF process.

_{Figure 3: Zero Trust DevOps Cycle from NIST CSWP 20}

In this loop, the data collected in the MONITOR step then feeds back into the IMPLEMENTATION step. As improvements and refinements are implemented, they are then assessed and follow the continual AUTHORIZE step to enter operations. If necessary, the DevOps/DevSecOps team may even fall back to the SELECT step if new information leads to new controls to be added or existing controls to be removed.

You should immediately be thinking about how technology and solutions can automate and orchestrate this process for your organization. One example would be leveraging an policy orchestration tool such as Cisco Secure Workload, which can automate the policy changes to other policy decisions and enforcement points. See an introduction in the video below:

_{Video 1: Cisco Secure Firewall + Cisco Secure Workload Integration}

Summary​

Zero trust is not a single technology solution, but a larger cybersecurity strategy and operational practice. A successful zero trust architecture requires the cooperation of cybersecurity planners, management, and administration/operations. Zero trust also requires the involvement of system, data, and process owners who may not traditionally provide input on the risks to their charges. This input is vital; zero trust is a holistic approach to enterprise cybersecurity and requires support from managers, IT staff and general enterprise users.

Are you just getting started on your journey? We can help, check out our Zero Trust Assessment & Strategy Service and Consulting Services, to learn how to optimize and accelerate your Zero Trust adoption.