Zero Trust Architecture: Rethinking Cybersecurity for Changing Environments

Zero Trust Architecture (ZTA) is not something you buy. It is an architectural approach—a way of thinking about cybersecurity which posits that traditional perimeter defenses aren't enough and cannot suffice to create a zone of trust in your network. Every asset in the environment should be protected, and every connection starts with Zero Trust. Trust must be earned on the basis of a risk-based access decision before each and every connection is allowed. Additionally, this trustworthiness must be continuously verified to maintain the connection. This article defines Zero Trust, identifies its characteristics, and provides strategies to start using a Zero Trust approach in your organization.

Why the Need for Zero Trust?

The border to the modern network is no longer clear:

• Users are logging in from home, from coffee shops and other public Wi-Fi, and from locations all over the world.
• All kinds of devices need to connect, including laptops, mobile devices, and Internet of Things (IoT) devices.
• Data and applications are no longer solely in an institution's data center but are located in multiple public, private, or hybrid clouds.

The traditional network perimeter as we've known it has also been under fire and is breached more often by attackers who are more capable and more persistent. When they do get in, it is important to detect and limit their lateral movement, inhibiting their ability to move about within the environment looking for valuable data to steal. As Virginia Tech's Randy Marchany pointed out in his presentation at the 2019 SANS Blue Team Summit, "It's a compromise if it stays inside my network; it's a breach if it leaves my network."^Footnote1

For these reasons, a ZTA assumes that threat actors are already in our network. Moreover, we can no longer rely on whether users and devices are "inside" or "outside" the network as the main criterion for allowing access to our organization's resources. Yet we still need to allow appropriate access while protecting our data. That's where a Zero Trust approach can help.

Timeline of Zero Trust

• 2003: The Jericho Forum, a group of interested chief information security officers (CISOs), is formed to discuss what they called the de-perimeterization problem.
• 2010: John Kindervag, then a Forrester Analyst, popularized the term "Zero Trust" and recommended treating every asset as if it were connected directly to the risk-infested internet. Therefore, all connections are untrusted.
• 2014: Google published whitepapers and other guidance on their model implementation of Zero Trust, called BeyondCorp.
• 2017: Forrester, led by Chase Cunningham, refined its original Zero Trust guidance, calling it Zero Trust eXtended.
• 2017: Gartner introduced its version of Zero Trust, calling it Continuous Adaptive Risk and Trust Assessment, or CARTA. It included a similar focus on access control and added a focus on protecting the enterprise from threats.
• 2020: NIST released its definition in "Special Publication 800-207: Zero Trust Architecture."^Footnote2
• 2021 to today: The industry has largely accepted the idea of Zero Trust and ZTA as the term for it. Zero Trust has become a buzzword, often used incorrectly.

Defining Zero Trust

Forrester is widely credited with popularizing Zero Trust and the follow-on, Zero Trust eXtended (ZTX).^Footnote3 Several basic principles of Zero Trust are:

• The network is always hostile.
• Internal and external threats are always present.
• Being on an internal network is not sufficient to be trusted.
• Every device, user, and network flow must establish trust before connecting.
• All events must be logged and inspected.

ZTX provides further detail, with the following as important considerations:

• Protecting data is at the heart of ZTX. Data should be classified by importance and sensitivity. Access to data should be secured on the basis of its classification using corresponding levels of isolation, encryption, configuration management, strength of authentication, access management, and log analysis.

Quick Tip: Think of workloads as the various information systems that encapsulate data and applications in your environment. Each workload might include things such as virtual PCs, portals, APIs, virtual network devices, virtual servers, databases, containers, applications, network segments, or microservices.

• People, devices, networks, and workloads use, hold, and move data (see figure 1). ZTX says we should treat all of them as if they are connected directly to the threat-riddled World Wide Web. As such, each should be individually protected, and connections between them are not automatically assumed safe because they are "in" the network. All connections must first earn trust before access is allowed.
• In order to make and enforce these trust-based access decisions, authorized IT staff must have visibility and analytics to provide real-time decisions for trusted access.
• With so much happening in the environment, automation and orchestration are critical to enforcing Zero Trust principles while providing trusted access for many disparate systems.

Forrester's vision of a ZTA contains many elements of a good security architecture that considers loss of data confidentiality as the primary risk and focuses on centralized control of security-related technologies to mitigate that risk. Although data confidentiality is always a leading concern, most higher education institutions include some mission-critical functions in which data and system availability and integrity are of equal or greater concern, and many are far from being entirely centralized organizations in which mission-affecting decisions are only made in a top-down manner. For most higher education institutions, the journey to Zero Trust will not look exactly like implementing the Forrester model, though that model reveals much of what the journey will entail.

NIST's Definition of Zero Trust

In "Special Publication 800-207: Zero Trust Architecture," the National Institute of Standards and Technology (NIST) acknowledges the work of Forrester and others to offer this operative definition of Zero Trust:

Zero Trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.^Footnote4

To explain and demonstrate, they provide a conceptual design (see figure 2) to describe the different components of a Zero Trust environment.

Access control is at the core of ZTA in NIST SP800-207, and its components are focused on making sure trust is established before every session from every subject to every resource. They define the "subject" as the user, device, or application that needs to have its trust established before being allowed to connect to an "enterprise resource."

• The Policy Engine (PE) uses your institution's policy as well as input from external sources (Policy Input Points, described below) as input to a trust algorithm to grant, deny, or revoke access to the resource. The PE makes and logs the decision, and the PA executes the decision.
• The Policy Administrator (PA) is responsible for enabling and/or shutting down the communication path between a subject and a resource via commands to associated Policy Enforcement Points (PEPs). The PA communicates with the PEP when creating the communication path. This communication is done via the control plane.
• The Policy Enforcement Point (PEP) takes action—it's responsible for allowing, monitoring, and terminating connections between a subject and an enterprise resource.

Policy Input Points (PIP) provide the policy and information needed to make and enforce the trust-based access decisions (see figure 3).

NIST gives the following examples of PIPs:

• A Continuous Diagnostics and Mitigation (CDM) System provides information about the enterprise's current environment. It gives visibility into who is in the environment; what devices, data, and applications are in the environment; and what is going on in the environment. It also includes the security devices that identify and respond to threats.

• Quick Tip: In this NIST definition, CDM refers generically to diagnostic, detection, and mitigation capabilities, not to the federal government program of the same name that provides these capabilities to federal agencies.

  The Threat Intelligence feed gives input from internal and external sources about newly discovered threats. A new malware or attack method being used elsewhere in the world or a newly discovered software vulnerability will likely require changes to the PE parameters.
• Most institutions need to meet general or industry-specific privacy and security obligations, such as government, financial, or healthcare regulations, as well as similar contractual obligations. These Industry Compliance needs are inputs to your policy decisions. Governance, risk, and compliance (GRC) tools can help monitor the environment to ensure an enterprise stays compliant.
• Data Access Policies are the attributes, rules, and policies that enterprise managers use to input their access decisions providing privileges for accounts, applications, and services.
• The enterprise Public Key Infrastructure (PKI) issues and manages certificates to facilitate encrypted communications.
• The ID Management System stores and manages identity information of users. This includes subject information such as name, email address, and authentication credentials. It should also include characteristics such as role, access attributes, and assigned devices to enable more granular access decisions by the PE.
• Network and System Activity Logs track asset logs, network traffic, resource access actions, and other events to inform control of your enterprise systems and historical visibility for incident investigations.
• The Security Information and Event Management (SIEM) System collects security information, including threat intelligence and network and system activity logs. It can produce reports for analysis or sound an alarm of a possible cyber attack. Information from the SIEM is used to change access decisions and modify policies in the PE/PA.

The NIST approach emphasizes the central role of Identity and Access Management in Zero Trust. It also recognizes "enterprise managers," who make data access policies for specific resources. This enables all parties with authority and perspective over the various granular activities of the organization's mission—regardless of their position within the organization—to provide their input into the means by which access is controlled. This is a good fit with the way many higher education institutions actually operate: central IT can operate the access control platform (PE/PA) and delegate to enterprise managers the ability to input their data access information.

Figure 4 is from the Cybersecurity and Infrastructure Security Agency's (CISA's) Zero Trust Maturity Model Draft,^Footnote5 which references the NIST Zero Trust document. It recognizes the need for institutional governance to determine general access policies and identify which people serve in the role of enterprise managers for which resources. This gives central IT the guidance it needs to configure and operate the technical components of the NIST architecture and delegate to enterprise managers in accordance with the institution's direction.

Because Zero Trust is an architectural approach, there are numerous variations of how to define and implement it. But the common trait is the focus on controlling access to an institution's assets as granularly as possible and requiring trust to be confirmed before access is granted—every time, to each asset.

Getting Started with a Phased Approach

The shift from perimeter-based security to an assumption of a completely untrusted network and shrinking the trust zone around each resource will not be easy for any institution. Your path will vary depending on your institution's goals, culture, and resources…and on the state of your current network. Consider the following steps as you plan your path to a Zero Trust environment:

Inventory the Current and Future States

Current State: Developing an inventory of the assets, devices, data flows, repository locations, and applications with sensitive data is critical to help shape the risk landscape and current state of ZTA maturity within your organization.

Desired End State: Determine what your ideal ZTA future state environment would be, including security strategy, security resources, processes, and technologies. Even if some elements are wishes, document your roadmap of where you'd like to go and how each recommendation for the future state better enables the organization's mission. This helps convey urgency, importance, budget needs, and risk.

Gap Plan and Funding Need: ZTA is a process that takes time to enhance your current security structure. Create a document detailing any gaps between desired future state and the current state of your organization. This document must also include risk prioritization (high = must address quickly, medium = complete as soon as possible, low = complete when time permits), ballpark effort to complete, and best time to implement this change based on resource timing/scheduling. This will help with buy-in to implement.

Develop a Plan

Executive and Departmental Buy-In: Institution-wide buy-in, process changes, and a new ZTA life cycle need to be infused across everyday activities starting with the purchasing life cycle when vetting new products and services. Therefore, everyone across the institution—the leaders, partners, vendors, and part-time employees—needs to be flexible as ZTA maturity evolves and as processes, tools, and requirements are being implemented. Executive-level buy-in is critical for supporting the visibility and viability of this initiative to drive security forward.

Management and Departmental Buy-In: It is critical that the current-state inventory is complete, or at least in progress, before seeking to gain management buy-in. Creating a plan that is achievable, with critical success factors defined, and that utilizes KPIs will garner support and champions. While establishing the need for Zero Trust, be action oriented and expect some resistance, given that the message you are sharing regarding the current state might be difficult for management to process, especially if they had a hand in developing what is currently in use. Finally, since Zero Trust constitutes such a significant culture shift, it requires frequent and various methods of communication.

Prioritization and Phased Approach: The Zero Trust model challenges and significantly changes the traditional network security architecture. Using the gap plan established when creating the current state inventory, plan for small shifts and an iterative approach to remove the greatest risk. Plan to reassess the current state and gaps to validate success. By demonstrating the reduction or mitigation of risk, and by empowering resource managers to manage access to their resources more effectively, you gain traction with those responsible for the funding, prioritization, and implementation of Zero Trust. Phases will range from weeks to years because the shift from perimeter-based to a completely untrusted network (utilizing the control plane) has various mitigations depending on the state of the current network.

Inventory Assets

Users and User Devices: Identifying all authorized users and their assigned or personal devices will allow you to develop and assign access policies for each (as outlined below).

Devices in Environment: Identifying what devices exist in an environment and whether they are cloud or on-prem helps identify the varying support, involvement, and co-location for each service.

Applications and Data (workloads, as described above): Gathering a list of all the enterprise architecture and subsequent data in the applications, where it's stored (DB, SAN, LAN, etc.), and controls for access will provide a baseline of information to assess risk for the current landscape.

Define and Implement Access Policies

Once you know who and what is in your IT environment—and what is going on in it—you can start developing and implementing network and application access policies based on risk-based trust decisions. Software-defined access (SDA) technologies enable you to input your risk-based decisions in the Policy Engine and enforce them through your environment.

Defining policies of what and how institutional resources can be accessed and used and by whom ensures that an Acceptable Use Policy, a Vendor Access Policy, a Security Policy, and a Privacy Policy can serve as reasonable controls to guide actions. Validating users based on enhanced access management and gathering heuristic data on user activity helps determine risk tolerance to establish trust.

Data should be classified. "Data classification" refers to the categorization of data and consistent application of security standards based on such categorization. Data should be classified according to your classification standard, and data should have only one classification level. Classification levels can include restricted, sensitive, internal, or public information.

Micro-segmentation means making your access control as granular as possible. The goal should be to have specific policies and control access for every session—this means allowing specific subjects access only to specific resources. For example, you might start by taking an incremental approach toward segmentation, starting with vLANs allowing access to certain groups of people or things in a particular vLAN, and then adding capabilities such as SDA tools to get to the ability to control individual access of each.

Your enforcement of access policy should include an ability to revoke access to subjects if their trust level drops unacceptably during a connection.

Maintain Continuous Access Verification and IT Visibility to React to Anomalies and Threats

Once granular access control policies are being enforced, it is important to evaluate their effectiveness, adjust as needed, and normalize them within your environment.

CDM tools should be used to monitor and defend your IT environment to make sure that the conditions used to make your access decisions do not change in a way that would threaten your security. Among many possible examples, this could include:

• A user with a mobile device who moves to an unsafe location
• A newly discovered threat that might affect your environment
• Unusual activity indicating a hijacked account or insider threat

The process of granting and rescinding access should be automated as much as possible.

Critical Factors to Apply Zero Trust at Your Institution

Several factors are vital to the successful implementation of and support for a Zero Trust approach.

Culture and Human Factors

There is more to Zero Trust than new technology. Changing people, processes, and policies can be one of the hardest parts of transitioning to a new approach. Zero Trust requires a culture shift away from having particular control already in place to helping users understand the needs for and foundations of Zero Trust. This includes all parties, from leadership to educators and students and even the IT managers and security staff. Change should promote the mission of the institution and enhance its unique culture. For example, showing how the added security of Zero Trust could allow users to connect to more applications from more places enhances the learning environment.

Data Encryption

In order to effectively limit access to the data, both at rest and in transit, encryption should be used. Data transfer should use (or be encapsulated with) HTTPS, SSH, IPsec, or similar protocols. Those protocols are usually used for internet-based communication. In ZTA, all network traffic should be relying on encryption because there is no inherent trust granted to the internal networks.

Data at rest should be stored on encrypted disks, depending on the capabilities of the operating system (third-party tools could be used if the OS doesn't provide such a feature). Encryption should also be extended to backup storage.

This may be challenging when troubleshooting; it may require decryption capabilities, such as key escrow or an internal Public Key Infrastructure (PKI).

Policy Creation and Access Control

The success of a Zero Trust–based implementation depends on enforcing risk-based policies and then successfully assessing trust to allow connections to institutional resources based on those policies. It is important to have an Identity and Access Management system that allows you to easily input your policies and enforce them throughout your environment.

Micro-Segmentation

Access policies should be enforced as granularly as possible, with the goal of virtually segmenting each individual enterprise resource. This allows for more flexibility and more individualization of your trust decisions and for access to be controlled for every data flow. If a threat does get into your environment, micro-segmentation limits that threat's ability to get past the border of this minimized segment to attack other resources.

Automation

The only way to keep up with so many policy inputs and so many trust decisions being made in a segmented Zero Trust environment is with automation and integration of your technology tools. Writing and maintaining Access Control Lists and other manual methods just cannot keep up.

Continuous Visibility and Enforcement

Knowing who's in your environment, what's in your environment, and what's going on in your environment are critical inputs to your Zero Trust posture. It's important to see any changes in your environment and be able to react to them by modifying access in response.

Threat Intelligence

Threat intelligence is an important PIP (policy input point) since it can change your access decisions. For example, if a new threat is found somewhere in the world and it attacks the operating system of subjects in your environment, then the access of those subjects must be reevaluated and you will likely want to quarantine those subjects until they can be patched.

Summary: What Zero Trust Should Be

Zero Trust is an architectural approach that helps you look at security differently to address the dispersed nature of your modern IT environment. It does not depend on being "inside" the perimeter but focuses on policy, identity, and posture to granularly control communications between users, systems, applications, and data.

• Zero Trust can enhance your security and can help you achieve the security requirements, certifications, and best practices needed by your organization.
• Zero Trust is a combination of policies, processes, and technologies that allow you to implement many of the capabilities that you probably already need in order to meet the cybersecurity needs of the modern campus environment.
• Zero Trust is a transformational business enabler. With the ability to protect every connection, you can confidently introduce new capabilities to students, faculty, and staff to give them greater flexibility and productivity.
• Zero Trust is a journey that will need engagement from the entire campus to begin and be sustained. As such, it can establish a rich set of institution-wide relationships to enhance awareness, ownership, and engagement that will have their own benefits beyond improved security.

Zero Trust focuses on allowing access to institutional resources only after trust is established for every connection. And it compensates for the reality that threats could be anywhere and that your intranet is likely no safer than the internet. It may seem daunting, but with modern technology that integrates and automates the environment, the environment is easier to manage and protect. Zero Trust is an approach that can help your institution meet its cybersecurity needs now and into the future.

Notes

1. Randy Marchany, "Zero-Trust Networks: The Future Is Here," SANS Blue Team Summit 2019. Jump back to footnote 1 in the text.↩
2. Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, "Zero Trust Architecture," NIST Special Publication 800-207, August 2020. Jump back to footnote 2 in the text.↩
3. Steve Turner and Chase Cunningham, "The Zero Trust eXtended (ZTX) Ecosystem," Forrester Research, August 23, 2021. Report is available to Forrester subscribers. Jump back to footnote 3 in the text.↩
4. Rose, Borchert, Mitchell, and Connelly, "Zero Trust Architecture." Jump back to footnote 4 in the text.↩
5. "Zero Trust Maturity Model" [https://www.cisa.gov/sites/default/files/publications/CISA%20Zero%20Trust%20Maturity%20Model_Draft.pdf], Cybersecurity and Infrastructure Security Agency, June 2021. Jump back to footnote 5 in the text.↩

---

Peter Romness is Cybersecurity Principal at Cisco Systems, Inc.

Heather Chester is ITS Senior Project Manager, Infrastructure, at Loyola University Chicago.

Sharyne A. Miller is Associate Vice Chancellor & Chief Information Officer at the University of North Carolina Wilmington.

Xavier Belanger is Network Engineer III at The Catholic University of America.

Tom Barton is Chief Information Security Officer (retired), University of Chicago.