Zero Trust Is the New Reality

The new cybersecurity executive order mandates zero-trust security requirements for federal information systems. Here's what you must know about the U.S. zero-trust standards from NIST.

The U.S. government mandated new zero-trust security requirements for federal information systems in an executive order issued on May 13. Federal agencies must respond in 60 days with plans to implement zero-trust architecture (ZTA) with standards and guidance from the National Institute of Standards and Technology (NIST). NIST and Tetrate have collaborated to create the standards that enterprises should follow.

Zero trust, first popularized by John Kindervag in 2010, is a network security model that shrinks the trust boundary around resources to zero — effectively protecting all internal assets as if they were exposed to the public Internet. Below is a brief overview of NIST zero-trust guidelines and four recommendations to help you understand the implications of the executive order for your own infrastructure.

ZTA IS BEYOND PERIMETER SECURITY

Traditional network security uses firewalls that separate sensitive internal systems from external networks and the Internet, theoretically protecting them from unauthorized access and potential threat from malicious actors. A critical flaw in the traditional approach is that if malicious actors can get through the firewall, they have access to the internal systems behind it.
ZTA assumes that perimeter network security can be potentially breached and recommends minimizing implicit trust zones, ideally to zero. It introduces a policy decision point (PDP) and policy enforcement point (PEP). Access to any enterprise resource must be dynamically authorized by the PDP and allowed to proceed by the PEP, regardless of network location.

WHAT ARE THE U.S. STANDARDS FOR ZERO TRUST?

NIST has authored a set of special publications (SPs) that provides a definition of ZTA and how it applies in various use cases as well as specific guidance for zero trust in microservices deployments.

DEFINITION OF ZERO TRUST

The standard definition of zero-trust architecture is described in SP 800-207, "Zero Trust Architecture," which establishes the tenets of zero trust and the logical components of a zero-trust architecture. The SP 800-204 series covers standards for security in microservices-based applications.

SECURITY STANDARDS FOR MICROSERVICES

The NIST SP 800-204 series — co-authored by Tetrate founding engineer Zack Butcher — offers security standards for microservices-based applications.

• "Security Strategies for Microservices-based Application Systems" offers a technology overview of microservices-based applications, a review of the threat landscape and general strategies for countering those threats. (SP 800-204)
  
• "Building Secure Microservices-based Applications Using Service-Mesh Architecture" provides guidance for deploying a robust security infrastructure for supporting microservices-based applications. It stipulates that a service mesh is the best known approach for facilitating the specification and implementation of zero trust in a microservices environment. (SP 800-204A)
  
• “Attribute-based Access Control for Microservices-based Applications Using a Service Mesh” provides deployment guidance for building an authentication and authorization framework with next-generation access control (NGAC) that meets the requirements of zero trust and robust access control. (SP 800-204B)

ZERO TRUST: NO SAFE PLACE ON THE NETWORK

Zero trust is an approach — a way of thinking about network security — more than it is any particular architecture or implementation. It starts from an assumption that there are no safe places on the network, and no resources should be accessible without appropriate protection. 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 be:

• Authenticated and dynamically authorized, not only at the network layer and the service-to-service layer but also at the application layer. Network location does not imply trust. Resource identity and end-user credentials are authenticated and dynamically authorized before any access is allowed.
  
• Bounded in space: The perimeter of trust around a service should be as small as possible. Network location alone does not imply trust. As such, all communication should be done in the most secure manner available. Also, access to one resource does not imply access to other resources.
  
• Bounded in time: Authentication and authorization are bound to a short-lived session, after which they must be re-established. Also, access should be granted with the least privileges required for the task.
  
• Encrypted, both to prevent eavesdropping and to ensure message authenticity and integrity.
  
• Observable, so the integrity and security posture of all assets can be continuously monitored and policy enforcement continuously assured. Also, insights gained from observing should be fed back to improve policy.

A litmus test for a zero-trust system is that any resource deployed in it wouldn’t have to change were it to be publicly exposed. If properly implemented, a zero-trust security architecture would be as secure when operating exposed to the public Internet as it is behind a firewall.

THE THREE COMPONENTS YOU NEED FOR ZTA

NIST's model contains three logical components to implement dynamic authorization and authentication:

1. a policy engine (PE) responsible for determining authorization
2. a policy administrator (PA) for establishing and/or shutting down the communication path to a resource based on results from the policy engine 
3. a policy enforcement point (PEP) that sits between the subject making a request and the destination resource that enables, monitors and terminates the connection between them (Fig. 2)

In this model, all workloads requested by the subject must have an identity that can be authenticated and authorized at the PEP. The PDP enforces policy over these identities and enforces authentication and authorization prior to allowing access. Here, authorization is based on fine-grained policy; reachability does not count as authorization. The PEP in the data plane allows for observability of systems at runtime and ensures continuous compliance and governance controls.

WHEN IS ZERO TRUST CRITICAL TO THE ENTERPRISE?

SP 800-207 calls out five common enterprise deployment scenarios where a zero-trust architecture is particularly applicable.

Satellite facilities. It may be impractical or impossible to route all remote employee traffic through the enterprise network. In this case, the policy engine and policy administrator are often hosted as a cloud service for superior availability.

Multicloud/cloud-to-cloud. Enterprises using multiple cloud providers may need to provide direct access between resources located in different clouds, bypassing the enterprise network for performance and ease of management. In this case, the zero-trust approach is to place policy enforcement points in front of each resource. This allows the enterprise to control policy for resources hosted outside the enterprise.

Contracted service and nonemployee actions. Enterprises may need to offer Internet access to on-site visitors and service providers but limit access to internal resources. In this case, PEs and PAs placed in front of sensitive resources can deny unauthorized access to those resources while allowing broader Internet access.

Collaboration across enterprise boundaries. Teams from different enterprises that need to collaborate with each other may need selective access to each other's enterprise resources. Providing outside users with temporary, specialized enterprise accounts can quickly become difficult to manage. In this case, both enterprises can enroll in a federated identity management system, eliminating the need for complex firewall rules or enterprisewide access control lists.

Public or customer-facing services. Enterprises that provide services to the public or to customers are constrained in what internal security policies they can enforce on those outside users. In this case, the dynamic attribute values and observability tenets of zero trust are particularly relevant. Detection and alerting of behaviors deviating from a known baseline can help security teams defend against automated attacks when, for example, there is a sudden increase in unknown or outdated browser requests. A security architecture sensitive to dynamic context and able to compare against a known-good baseline can help enterprises defend against such attacks.

TAKE YOUR NEXT STEP

Zero trust is a fundamental shift from previous network security practices, providing much-needed improvements at both the network and application level. We hope this article provides some clarity around the standards that federal enterprises will be expected to meet in their journey to zero trust.

The challenge enterprises face now is how to make the shift to zero trust for a modern application fleet composed of both traditional and cloud-native architectures. Any solution will need to offer globally managed policy enforcement points between all services and applications, inserting zero-trust capabilities like SSO, mTLS and dynamic authorization. As the NIST standards suggest, service mesh is an important part of such a solution. A comprehensive platform that offers the capabilities of a service mesh universally across all environments and any compute would be even better.

Tetrate Service Bridge (TSB) offers just such a solution: an end-to-end application networking platform that provides comprehensive out-of-the-box cybersecurity features for application components, including strong workload identity, authentication, encryption, and fine-grained, dynamic authorization and access control. TSB prevents lateral movement of threat actors by creating enforcement perimeters around individual workloads, collections of app components or entire network domains, implementing a zero-trust approach across hybrid and multicloud environments, bridging traditional monoliths and microservices architectures. Visit tetrate.io for more information on how Tetrate can help you get to zero trust.