Log in / Register Account
Jump to section

What is Zero Trust?

Copy URL

Zero Trust is an approach to designing security architectures based on the premise that every interaction begins in an untrusted state. This contrasts with traditional architectures which may determine trustworthiness based on whether communication starts inside a firewall. More specifically, Zero Trust attempts to close gaps in security architectures that rely on implicit trust models and one-time authentication.

Zero Trust has gained popularity because the global threat landscape has evolved, challenging long held assumptions about the inherent trustworthiness of activities inside a network. Well-organized cybercriminals can recruit insiders, and continue to find new ways past the outer shell of traditional security architectures. Sophisticated hacking tools and commercialized ransomware-as-a-service platforms have also become more widely available, making it easier for new kinds of financially-motivated criminals and cyber terrorists to operate. All of these threats have the potential to exfiltrate valuable data, disrupt business and commerce, and impact human life.

Given this new threat landscape, The United States Federal Government is under Executive Order to advance toward a Zero Trust architecture, and many enterprises are weighing the costs and benefits of adopting this approach.

In a well-known 2010 Forrester report on Zero Trust, John Kindervag called for an end to this prevailing motto in information security: "We want[ed] our network to be like an M&M, with a hard crunchy outside and a soft chewy center." For decades, enterprises had been designed this way, with a trusted or internal network (the chewy center) separated from the external world by a perimeter of firewalls and other security defenses (the crunchy outside). Individuals or endpoints within the perimeter, or connected via remote methods, got a higher level of trust than those outside the perimeter.

This "hard shell, soft center" approach to security design was arguably never ideal, but continues to persist today. These architectures make it easy to traverse the internal network once inside, with users, devices, data, and other resources minimally separated. Cyberattacks take advantage of this design by first gaining access to one or more internal endpoints or other assets before moving laterally across the network, exploiting weaknesses, exfiltrating controlled information, and launching further attacks.

In addition to its susceptibility to sophisticated cyber attacks, this insufficient architecture becomes strained as networks expand to include a vast number of endpoints, with users requiring access from more locations and to more assets with finer-grain services. The COVID-19 pandemic and an increasingly remote workforce, in addition to growing workloads in the cloud, have drawn additional attention to the issue of trust.

The foundations of Zero Trust security are de-perimeterization and least privilege, which protect data, assets, and services from vulnerabilities inherent in network perimeter and implicit trust architectures.

De-perimeterization: Enterprises are no longer defined by geographic perimeters. Users operate from a variety of locations and endpoints, accessing resources from one or more operational environments, including cloud and Software-as-a-Service (SaaS) solutions, often not owned or controlled by the enterprise IT organization. De-perimeterization addresses this decoupling of trust from location.

Least privilege: When interactions cannot inherit trust based on name or location, every interaction is suspect. Deciding whether to allow any interaction becomes a business decision that must take into account the benefits and risks of doing so. Least privilege refers to the practice of restricting access to only those resources absolutely necessary—i.e. the "least" privileges necessary for an activity. Each request for access to a resource needs to be dynamically validated using identity management and risk-based, context-aware access controls.

Implementing a Zero Trust architecture does not require a comprehensive replacement of existing networks or a massive acquisition of new technologies. Instead, the framework should strengthen other existing security practices and tools. Many organizations already have the necessary foundation for a Zero Trust architecture and follow practices that support it in their day-to-day operations.

For instance, these critical components needed for successful adoption of Zero Trust may already be present as part of a conventional security architecture:

  • identity

  • access

  • authorization

  • automated policy decisions

  • ensuring resources are patched

  • continuous monitoring with transactions that are logged and analyzed

  • repeatable activities that are prone to human errors automated as much as possible

  • behavioral analytics and threat intelligence used to improve asset security

In fact, Zero Trust is already being practiced today at various scales and against a wide array of environments. Its core tenants primarily require the application of existing security practices, and organizational and process controls. Federal organizations like the US Department of Defense, Homeland Security, and the Intelligence Community—where security is a central cultural pillar—have already made significant progress toward implementing a Zero Trust security model.

Zero trust as a security model is often described in abstract terms, as opposed to more formalized controlled access models such as Bell-LaPadula. There are different sets of components espoused by different groups or standard bodies. A typical set of components might be:

  • Single strong source of identity for users and non-person entities (NPEs)

  • User and machine authentication

  • Additional context, such as policy compliance and device health

  • Authorization policies to access an application or resource

  • Access control policies within an application

These components are largely focused on how to implement identity based access control mechanisms with a default "deny-all" and "allow-by-exception."

Trust boundary

A trust boundary is any logical separation between components where the subjects participating in an interaction change their trust status, typically between the two states of "trusted" and "untrusted." Generally the transition from untrusted to trusted requires two things:

  • authentication: verification and/or validation of the identity of the subjects. 

  • authorization: verification and/or validation of the right to and need to access an asset (data, systems, or other).

In order to adhere to Zero Trust principles, trust boundaries must be kept as small as possible—by definition, within the boundary, subjects are trusted and access controls may be omitted, bypassed, or otherwise limited. Since the authorization should be for only specific business functions, any boundary that allows access to other functions should be narrowed.

Not all security boundaries in a system architecture need to fit the criteria of a proper Zero Trust boundary. These ordinary boundaries—such as filtering unwanted IP addresses, allowing certain protocols to access a network, or limiting social media use—can overlap Zero Trust and still play a role in security. The critical difference in adopting Zero Trust, however, is that ordinary boundaries are not part of calculating trust, as they might have in traditional architectures. Only boundaries that meet Zero Trust principles should play a role in calculating trust.

Zero Trust requires the separation between distinct subjects to always be maintained: that is to say, there is always a trust boundary between any two subjects and thus every interaction requires direct authentication and authorization. There is no implicit trust by virtue of two subjects being on the same network (a very common scenario), nor being available in the same physical location, nor part of the same line of business or integrated system.

A Zero Trust security model works by enforcing these trust boundaries. Typically this is done by interposing an enforcement point between all potential interactions with all resources. As these interactions change over time, so do the identities, resource states, and other aspects of a system. This continuous change requires an equally continuous assessment and monitoring of identities and resources, and continuous reevaluation and enforcement of authentication and authorization.

There are still many areas where these basics are simply too constrained to implement. Continued use of legacy technology, immature business processes, or the low priority of security as an essential business function are all common challenges.

Zero Trust often requires a change of mindset for both leadership and security professionals. Leaders need to evaluate the risk of maintaining existing, outdated security architectures. IT and operational technology (OT) professionals need to recognize where they can take advantage of existing investments to reduce the cost to implement Zero Trust, and where to prioritize new investments. However, it is a reality that some protocols and devices will never be Zero Trust, in which case decisions have to be made whether to replace or maintain them. Moreover, if certain systems can’t fully embrace a Zero Trust model, OT professionals must ask themselves what the mitigating controls are, and whether alternative security controls can be applied to further reduce their exposure.

The move to "deny by default," the basic premise of Zero Trust, requires commitment from teams to both implement and maintain over time, while ensuring no part of the organization attempts to work around the Zero Trust security architecture by creating "shadow IT" offerings.

Red Hat can help get you started with Zero Trust adoption. Initially, enterprises must understand and be committed to implementing Zero Trust. General cybersecurity awareness is an important prerequisite in order to get stakeholders to proceed—to understand the nature of the current threat environments and how existing security practices are important and yet incomplete without following Zero Trust principles. Red Hat offers options for this training and education through customized experiences delivered through Red Hat Open Innovation Labs or other specialized Red Hat Services engagements.

Red Hat OpenShift Container Platform

Red Hat® OpenShift® Container Platform provides automation of access controls and non-bypassable enforcement via admission controllers.

Red Hat Ansible Automation Platform

Red Hat® Ansible® Automation Platform (AAP) allows for declarative discovery of systems and consistent configuration of access control implementations.


Want to dig deeper?


What is hybrid cloud security?

Hybrid cloud security is the protection of the data, applications, and infrastructure associated with an IT architecture that incorporates some degree of workload portability, orchestration, and management across multiple IT environments, including at least 1 cloud—public or private.


What is DevSecOps?

DevSecOps stands for development, security, and operations. It's an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle.


Unlocking zero trust supply chains

In S01E08 of Technically Speaking, Red Hat Software engineer and Sigstore project founder Luke Hinds joins Red Hat CTO Chris Wright to discuss Zero Trust and supply chain security with code signing for open source projects.