Overview
Zero Trust Security—sometimes called Zero Trust Architecture (ZTA) and Zero Trust Network Access (ZTNA)—is an information security model that requires strict identity verification for all users, devices, and applications attempting to access resources within a network, regardless of their location. Popularized by John Kindervag at Forrester in 2010, the basic idea of the zero trust model is to never trust any user, device or application automatically—even if it appears to be legitimate or is within the organization’s perimeter.
Instead, Zero Trust requires continuous verification and authentication of users and devices before granting access to any network resources. This is typically done through multi-factor authentication, role-based access control and monitoring of user activity to detect and respond to any suspicious behavior.
Zero Trust also requires strict segmentation of network resources, so users and devices only have access to the resources they need to perform their tasks, and nothing more. This reduces the risk of lateral movement by attackers who may gain access to one part of the network and then move laterally to gain access to more sensitive resources.
Zero Trust systems have a simple litmus test: if exposed to a public network, they wouldn’t need to change. If properly implemented, a Zero Trust security architecture would be as secure on the public Internet as it is behind a firewall.
Principles of Zero Trust
Zero Trust is an approach—a way of thinking about network security—more than it is any particular topology, technology, or implementation. It starts from an assumption that there are no safe places on the network.
In the Zero Trust model, unlike traditional perimeter security, reachability does not imply authorization. Zero Trust seeks to shrink implicitly trusted zones around resources, ideally to zero. In a Zero Trust network, all access to resources should:
Assume a breach. Zero Trust assumes attackers may already be present within the network, and therefore requires continuous monitoring and analysis of user and device behavior to detect and respond to any suspicious activity.
Authenticate and dynamically authorize access. Authentication and authorization should be verified not only at the network layer and the service-to-service layer, but also at the application layer. Network location does not imply trust. Service identity and end-user credentials are authenticated and dynamically authorized before any access is allowed.
Bind trust in space. The perimeter of trust around a resource should be as small as possible.
Bind trust in time. Authentication and authorization should be bound to a short-lived session and re-established frequently.
Encrypt communication. Network communication should be encrypted to prevent eavesdropping and to ensure messages are authentic and unaltered.
Use least privilege access. Zero Trust requires granting users and devices only the minimum level of access required to perform their tasks, based on their roles and responsibilities within the organization.
Ensure observability. A Zero Trust system should be observable so the integrity and security posture of all assets may be continuously monitored and policy enforcement continuously assured. Also, insights gained from observing should be fed back to improve policy.
Zero Trust vs Perimeter Security
Perimeter security is based on the idea of creating a secure boundary around an organization’s network, typically using firewalls and other network security devices to block unauthorized access from external sources. Once a user or device is inside the perimeter, however, it is often assumed to be trusted and granted access to network resources without further authentication or verification.
Traditional network security models that rely on a hardened perimeter have become less effective in the face of advanced persistent threats and targeted attacks. With the rise of cloud computing, mobile devices, and remote work, traditional network perimeters have become less relevant, making it easier for attackers to infiltrate networks and gain access to sensitive data.
Zero Trust, on the other hand, assumes that all users and devices,, both internal and external, may be potential threats and requires continuous verification and authentication of their identity and access permissions. This means that users and devices—and other system components—must be authenticated and authorized every time they attempt to access network resources, even if they are already inside the organization’s perimeter.
Additionally, Zero Trust requires strict segmentation of network resources, so that users and devices only have access to the resources they need to perform their tasks, and nothing more. This reduces the risk of lateral movement by attackers who may gain access to one part of the network and then move laterally to gain access to more sensitive resources.
Benefits of Zero Trust Architecture
- Accessibility is not authorization—unlike perimeter security, access to a resource is not granted solely because that resource is reachable; it must be explicitly authenticated and authorized as well.
- Authenticated and authorized resources are protected from perimeter breaches.
- Bounding trust in time limits the risk of compromised credentials.
- Bounding trust in space allows for high granularity of policy enforcement.
- Dynamic policy enforcement ensures authorization policy is up-to-date.
- Encryption limits reconnaissance and ensures authenticity of communication.
- Least privilege ensures that users, applications, and systems have only the access rights and permissions necessary to perform their specific functions. This approach helps prevent unauthorized access to sensitive data and resources and limits the damage that can be caused by a security incident
- Fine-grained observability allows real-time assurance policy is being enforced and allows post-facto auditability of how policy has been enforced historically, plus the necessary data for troubleshooting and analysis.
Challenges of Implementing Zero Trust
While Zero Trust architecture offers many benefits, there are also several challenges organizations may face when adopting this approach:
Complexity. Implementing Zero Trust architecture requires a comprehensive understanding of an organization’s network environment, including all users, devices, applications and data. This can be a complex and time-consuming process, especially for organizations with large, distributed networks.
User experience. Zero Trust requires continuous authentication and verification of users and devices, which can impact the user experience. If authentication processes are too cumbersome or time-consuming, users may resist using the system, leading to lower productivity and user satisfaction.
Cost. Implementing Zero Trust architecture requires investment in new technologies, such as identity and access management systems, behavioral analytics tools, and network segmentation solutions. This can be costly, especially for smaller organizations with limited budgets.
Legacy systems. Many organizations still rely on legacy systems and applications that may not be compatible with Zero Trust architecture. Upgrading these systems can be costly and time-consuming.
Culture and organizational change. Implementing Zero Trust architecture requires a cultural shift within an organization, as it requires a change in the way users and devices are granted access to network resources. This can be challenging, especially in organizations with a long history of traditional perimeter security approaches.
Training and education. Adopting Zero Trust architecture requires training and education for IT staff and end-users to understand the new security protocols and practices. This can be time-consuming and costly, especially for organizations with large and distributed workforces.
U.S. Government Standards for Zero Trust Security
The US government has published several standards and guidelines for Zero Trust Architecture. One of the most notable is the National Institute of Standards and Technology (NIST) Special Publication 800-207, which provides an overview of Zero Trust Architecture and its key components. NIST has also published the SP 800-204 series on Zero Trust security recommendations for microservices applications.
The Cybersecurity and Infrastructure Security Agency (CISA) has also published guidance on implementing Zero Trust, including a Zero Trust Maturity Model to help organizations assess their current level of implementation.
Additionally, the Office of Management and Budget (OMB) has issued a memorandum on Zero Trust Architecture implementation, outlining the government’s commitment to transitioning to a Zero Trust model and providing guidance for agencies to follow.
Service Mesh as a Critical Component of a Zero Trust Architecture
In SP 800-204B, NIST has established a reference platform consisting of Kubernetes for orchestration and resource management, with Istio service mesh providing the core security features.
A service mesh is important because it closes certain gaps in the communication mechanism of Kubernetes. Kubernetes has some limitations the service mesh addresses, including insecure communications by default, lack of built-in certificate management mechanisms, lack of service identity and access management and firewall policy that operates at OSI L3, but not L7 and is, therefore, unable to peek into data packets or make metadata-driven decisions.
Kubernetes doesn’t address certain application-level development and operational needs unique to microservices the service mesh was designed to satisfy. A service mesh provides a unified way to address cross-cutting application concerns, standard plugins to quickly address those concerns and a framework for building custom plugins. It also manages operational complexity, enables easy governance of third-party developers and integrators, and can reduce costs for development and operations.
Istio’s data plane of Envoy proxies provides authentication and authorization, secure service discovery via a dedicated service registry, secure communications including mTLS and encryption, network resilience and unified observability data. Istio’s ingress controller provides a common, external-facing API for all clients, protocol translation, composition of results, load balancing and public TLS termination. Istio’s egress controller provides a single, centralized set of whitelisted external workloads, credential exchange and protocol translation back to web-friendly protocols.
- Learn more about the Istio service mesh ›
- Get started with Istio using Tetrate Istio Distro, Tetrate’s hardened, performant, and fully upstream Istio distribution ›