The National Cybersecurity Strategy was released on March 1, 2023, in which the Biden administration committed to improving federal cybersecurity through the implementation of a zero trust architecture (ZTA) strategy and the modernization of information technology (IT) and operational technology (OT) infrastructure.

In 2022, we hosted Zero Trust Industry Days, which featured keynote addresses; presentations from zero trust (ZT) vendors; a question-and-answer session; and panel discussions among experts from government and industry, and research leaders. During these discussions, participants identified ZT-related issues that could benefit from additional research. By focusing on these areas, organizations in government, academia, and industry can collaborate to develop solutions that streamline and accelerate ongoing ZTA transformation efforts. In this blog post, which is excerpted from a recently published white paper, we highlight eight potential research areas.

Area 1: Agree on a Generally Accepted Set of Basic ZT Definitions

According to NIST SP 800-207, Zero Trust Architecture, ZT access decisions are made on a per-session basis. However, there are several definitions of the term “session,” and panelists at the Zero Trust Industry Day 2022 event emphasized the importance of defining that and other terms, including per session, per-request access, and per-request logging.

Panelist Paul Martini of iboss described a session as a central concept in ZTA that generally refers to the specific instance when a user gains access to an enterprise resource.

Although NIST SP 800-207 states that access decisions are made on a per-session basis, NIST also released CSWP 20, which explicitly states that “the unit of ‘session’ can be nebulous and differ depending on tools, architecture, etc.” NIST further describes a session as a “connection to one resource utilizing one network identity and one privilege for that identity (e.g., read, write, delete, etc.) or even a single operation (similar to an API call).” Since this definition may not always correspond to real-world implementations, however, NIST also defines session more generally: “[a] connection to a resource by a network identity with set privileges for a set period of time.”

This broader definition implies that reauthentication and reauthorization are periodically required in response to privilege escalation, timeouts, or other operational changes to the status quo. Similarly, comprehensive definitions are also needed for other concepts (e.g., per-request access and per-request logging). Defining, standardizing, and reinforcing these concepts will help to solidify the industry’s overall understanding of ZT tenets and describe how they will look in practice.

Area 2: Establish a Common View of ZT

From an operational perspective, organizations can benefit from an established, open-source standard for defining event communication among ZT components. Organizations must also understand how they can leverage new and existing frameworks and standards to maximize ZT interoperability and efficacy.

Using a common protocol could allow greater integration and communication among individual components of a ZT environment. Panelist Jason Garbis from Appgate suggested a notable example of such a protocol: the OpenID Foundation’s Shared Signals and Events (SSE) Framework. That framework helps standardize and streamline the communication of user-related security events among different organizations and solutions.

Another area worth exploring is policy decision points (PDPs) and related elements used throughout an enterprise environment. Existing solutions may leverage unique workflows to develop instruction sets or operating parameters for the PDP. For access-related decisions, the PDP relies on policies, logs, intelligence, and machine learning (ML). There is little discussion, however, about how these factors might work in practice and how they should be implemented. To encourage uniformity and interoperability, security organizations could develop a standardized language for PDP functionality, similar to the STIX/TAXII2 standards developed for cyber threat intelligence.

Area 3: Establish Standard ZT Maturity Levels

Existing ZT maturity models do not provide granular control or discussion of the minimal baselines required for effective shifts to ZT. It is important to consider how to develop a maturity model with enough levels to help organizations identify exactly what they must do to meet ZT standards for basic security.

Panelist Jose Padin from Zscaler emphasized the need to define the minimum baseline requirements necessary for ZTA in the real world. It is critical to establish a standard of technical requirements for ZT maturity so that organizations can identify and audit their progress toward digital trust.

In his presentation, Padin highlighted some of the strengths of the CISA Zero Trust Maturity Model, which features several pillars depicting the various levels of maturity in the context of ZT. [For a high-level view of CISA’s Zero Trust Maturity Model, refer to Figure 2 (page 5) of the Zero Trust Maturity Model.]

The CISA model helps organizations visualize best practices and their associated maturity levels, but there is still considerable uncertainty about what the minimum requirements are to achieve ZT. Organizations cannot assess their current state of ZT maturity and choose their best course of action without clear criteria to compare against.

The CISA Zero Trust Maturity Model progresses from Traditional to Advanced to Optimal, which may not provide enough granular insight into the middle ground where many organizations will likely find themselves during the transitional phases of ZT transformation. Moreover, while CISA’s model defines the policies and technologies that determine each level of maturity, there is minimal technical discussion about how these concepts might work in practice.

It is necessary to (1) address the stratification of ZT maturity and (2) provide organizations with sufficient reference materials and guidance so they understand where they currently stand (i.e., their “as-is” state) and where they need to go (i.e., their “to be” state). Organizations would benefit from more information about how to implement ZT strategies across their digital assets to achieve compliance, similar to the concept of a minimum viable product.

Area 4: Explain How to Progress Through ZT Maturity Levels

For successful ZT transformation, it is important to do the following:

• Understand the specific steps an organization must take.
• State the transformation process directly and logically.
• Identify how organizations can achieve digital trust.

Building on Area 3: Establish Standard ZT Maturity Levels described above, organizations in the security space must identify the minimum steps required to implement ZT at some level while also demonstrating how those steps might look in practice. Once an organization has begun implementing ZT, it can work toward higher levels of ZT maturity, with the ultimate goal of achieving digital trust.

According to the Information Systems Audit and Control Association (ISACA), digital trust refers to the “confidence in the integrity of the relationships, interactions and transactions among suppliers/providers and customers/consumers within an associated digital ecosystem.” In essence, ZT serves as the foundation for interaction among entities from a cybersecurity perspective. Digital trust encompasses all the interactions between internal and external entities more comprehensively.

Implementing ZT and achieving digital trust require strong collaboration between government and private-sector organizations. Government and related entities must actively collaborate with private-sector organizations to align models, standards, and frameworks with real-world products and services.

This approach provides end users with useful information about how a particular product can leverage ZT strategies to achieve digital trust. These collaborations must focus on identifying (1) what a security offering can and cannot do, and (2) how each offering can integrate with others to achieve a specific level of compliance. This information enables organizations to act more quickly, efficiently, and effectively.

Area 5: Ensure ZT Supports Distributed Architectures

With the increasing adoption of cloud solutions and distributed technologies (e.g., content delivery networks [CDNs]), it is necessary to develop security frameworks that account for applications and data moving away from a central location and closer to the user.

When developing frameworks and standards for the future of ZT, it is important to consider that offsite data storage is being moved closer to the consumer, as demonstrated by the prevalence of CDNs in modern IT infrastructures.

Panelist Michael Ichiriu of Zentera suggested that researchers consider exploring this topic in the context of new security frameworks since many existing frameworks take a centralized data center/repository approach when describing security best practices. This approach underserves CDN-oriented organizations when they are developing and assessing their security posture and architecture.

Area 6: Establish ZT Thresholds to Block Threats

In a ZT environment, it is important to understand what constitutes the minimum amount of information required to effectively isolate and block an activity or piece of malware. Identifying this information is essential since a growing number of ransomware attacks are using custom malware. To defend against this threat, organizations must improve their ability to detect and block new and adapting threats. An important aspect of ZT is using multiple strategies to detect and isolate attacks or malware before they spread or cause damage.

A properly implemented zero trust architecture should not trust unknown software, updates, or applications, and it must quickly and effectively validate unknown software, updates, and applications. ZT can use a variety of methods (e.g., sandboxes and quarantines) to test and isolate new applications. These results must then be fed into the PDP so that future requests for those applications can be approved or denied immediately.

Area 7: Integrate ZT and DevSecOps

In the development process, it is important to use as many security touchpoints as possible, especially those related to ZT. It is also important to understand how to emphasize security in an organization’s development pipeline for both conventional and emerging technologies.

These considerations lead us into the realm of DevSecOps, which refers to a “set of principles and practices that provide faster delivery of secure software capabilities by improving the collaboration and communication between software development teams, IT operations, and security staff within an organization, as well as with acquirers, suppliers, and other stakeholders in the life of a software system.”

As automation becomes more prevalent, DevSecOps must account for the possibility that a requestor is automated. ZTA uses the identity of the workloads that are attempting to communicate with one another to enforce security policies. These identities are continuously verified; unverified workloads are blocked and therefore cannot interact with malicious remote command-and-control servers or internal hosts, users, applications, and data.

When developing software, everyone historically assumed that a human would be using it. When security was implemented, therefore, default authentication methods were designed with humans in mind. As more devices connect with one another autonomously, however, software must be able to use ZT to integrate digital trust into its architecture. To enable the ZT strategy, DevSecOps must be able to answer the following questions:

• Is the automated request coming from a trusted device?
• Who initiated the action that caused the automated process to request the data?
• Did an automated process kick off a secondary automated process that is now requesting the data?
• Does the human who configured the automated processes still have access to their credentials?

Area 8: Set Business Expectations for ZT Adoption

Security initiatives are frequently expensive, which contributes to the organization’s perception of security as a cost center. It is important to identify inefficiencies (e.g., obsolescence) during the ZT transformation process. It is also crucial that organizations understand how to use ZT to maximize their return on investment.

ZT is a strategy that evaluates and manages the risk to an organization’s digital assets. A ZT approach shifts the defenses from the network perimeter to in-between digital assets and requires session authentication for all access requests. Many ZT strategies can be implemented with a reasonable amount of effort and at a low cost to the organization. Examples include micro-segmentation of the network, encryption of data at rest, and user authentication using multi-factor authentication.

However, some solutions (e.g., cloud environments) require a lengthy transition period and incur ongoing costs. Since organizations have unique risk tolerance levels, each organization must develop its own ZT transformation strategy and specify the initial phases. Each of these strategies and phases will have different costs and benefits.

A Platform for Shared ZT Discussions

The SEI’s Zero Trust Industry Day 2022 was designed to bring vendors in the ZT field together and offer a shared platform for discussion. This approach allowed participants to objectively demonstrate how their products could help organizations with ZT transformation. Discussions included several areas that could use more exploration. By highlighting these areas of future research, we are raising awareness, promoting collaboration among public and private-sector organizations to solve real-world problems, and accelerating ZT adoption in both government and industry.