ZTNA is a security strategy (not a product) that says that all devices and users are considered untrusted until they can be authenticated.
Zero Trust is a term coined by John Kindervag while he was an analyst at Forrester Research to describe a strategic framework in which nothing on the network is trusted by default—not devices, not end users, not processes. Everything must be authenticated, authorized, verified and continuously monitored.
The traditional approach to security was based on the concept of “trust, but verify.” The weakness of this approach is that once someone was authenticated, they were considered trusted and could move laterally to access sensitive data and systems that should have been off-limits.
Zero Trust principles change this to “never trust, always verify.” A Zero Trust architecture doesn’t aim to make a system trusted or secure, but rather to eliminate the concept of trust altogether. Zero Trust security models assume that an attacker is present in the environment at all times. Trust is never granted unconditionally or permanently, but must be continually evaluated.
[ Download our editors’ PDF Zero Trust network access enterprise buyer’s guide today! ]
The development of a Zero Trust approach is a response to the traditional methods of how enterprise assets, resources and data were accessed over the years. In the early days of computing, companies were able to protect their data through the use of firewalls and other security technologies that set up a “secure perimeter” around the data. Much like a castle wall in medieval times, these technologies helped protect what was inside (for the most part).
But the perimeter soon changed, as employees, contractors, and business partners began working remotely – accessing resources via cloud-based networks or with personally owned devices that couldn’t always be verified as completely secured. In addition, the deployment of Internet of Things (IoT) devices, which often had automatic access to network resources, increased.
To allow employees to access network resources, a Zero Trust architecture requires a combination of technologies, including identity management, asset management, application authentication, access control, network segmentation, and threat intelligence.
The balancing act of Zero Trust is to enhance security without sacrificing the user experience. Once authenticated and authorized, a user is given access, but only to the resources they need in order to perform their job. If a device or resource is compromised, Zero Trust ensures that the damage can be contained.
The good news for many companies is that they have likely already invested in several of the Zero Trust enabling technologies. In adopting a Zero Trust approach, companies will more likely need to adopt and enforce new policies, rather than install new hardware.
What are the basic ZTNA concepts?
Before you start deploying a Zero Trust architecture, there are several basic rules that must be followed across the company in order for the system to work.
– All data sources, computing services, and devices are considered resources. Even employee-owned devices must be considered a resource if they can access enterprise-owned resources.
– All communication should be secured, regardless of the network location. Devices and users inside a network are just as untrustworthy as those outside the network perimeter.
– Access to resources is granted on a per-session basis, and with the least privileges needed to complete a task. Authentication to one resource does not automatically grant access to a different resource.
– Access to resources is determined through a dynamic policy that includes the state of a client’s identity, application, and may include other behavioral and environmental attributes.
– An enterprise must monitor and measure the integrity and security posture of all owned and associated assets. Continuous diagnostics and mitigation (CDM) or similar systems to monitor devices and applications is required. Patches and fixes need to be applied quickly. Assets discovered to have known vulnerabilities can be treated differently (including denial of connection) than devices or assets deemed to be in their most secure state.
– Authentication and authorization are strictly enforced before access is allowed, and can be subject to change. Authorization given on one day does not guarantee authorization on the next.
– An organization needs to collect as much information as possible about the current state of their assets, network infrastructure, communications, end users and devices in order to improve their security posture. Only with these insights can policies be created, enforced, and improved.
How to implement Zero Trust
Once these tenets are understood and applied, a company can begin to implement a Zero Trust strategy. This includes these five steps:
- Identify the resources that need to be protected. Terms vary – some call it the “protect surface,” others call it the “implicit trust zone.” But it’s basically a clearly defined area in which Zero Trust processes will occur, which depends on the business and their needs. Prioritizing the areas for protection can keep these zones small, at least initially.
- Map transaction flows for these resources. Companies need to identify who typically needs access to those resources, how they connect, and what devices they use to connect.
- Build the architecture. This includes adding components that allow or deny access to those protected resources.
- Create a Zero Trust policy that indicates user roles, authorizations, how people will authenticate (multifactor authentication is a must-have).
- Monitor and maintain the system, making changes and improvements as needed.
What is a Zero Trust architecture?
Once a resource has been identified as protected, a company needs to set up “checkpoints” that are responsible for the decision to allow or deny access. There are three main components, based on terms coined by NIST in its Zero Trust Architecture document from August 2020)
- Policy Engine (PE). A policy engine (PE) is responsible for making the decision to grant or deny access to a resource. It generally makes the decision based on enterprise policy, but also gets input from external sources (including CDM systems, threat intelligence services) and the trust algorithm. Once a decision is made, it is logged and the policy administrator executes the action.
- Policy Administrator (PA): The PA is responsible for establishing or shutting down the communication path between a requestor (either a person or machine) and the resource (data, service, application). The PA can generate session-specific authentication (or use tokens, credentials, passwords) as part of its process. If a request is granted, the PA configures the Policy Enforcement Point (PEP) to allow the session to start. If a request is denied, the PA tells the PEP to shut down the connection.
- Policy Enforcement Point (PEP): The PEP enables, monitors, and eventually terminates connections between a requestor and the resource. It communicates with the PA to forward requests, as well as receive policy updates from the PA.
Additional systems can contribute input and/or policy rules, including CDM systems, industry compliance systems (making sure that these systems remain compliant with regulatory agencies), threat intelligence services (giving information about newly identified malware, software flaws, or other reported attacks), network and system activity logs, and identity management systems (to keep track of updated roles, assigned assets, and other attributes).
Many of these systems feed data into a trust algorithm that helps make the ultimate decision for the request to access network resources. The trust algorithm considers data from the requestor as well as a number of other metrics as part of its decision. Examples of questions include, but are not limited to:
- Who is this person? Is it a real person or a machine? (IoT sensor, e.g.)
- Have they requested this before?
- What device are they using?
- Is the OS version updated and patched?
- Where is the requestor located? (home, overseas, etc.)
- Does the person have the rights to view this asset?
Deployment scenarios for ZTNA
Every company is different, so the way they approach Zero Trust will vary. Here are a few common scenarios:
- An enterprise with satellite offices. Companies that have employees working at remote locations, or remote workers, would likely need to have a PE/PA hosted as a cloud service. This provides better availability and doesn’t require remote workers to rely on enterprise infrastructure to access cloud resources. In this scenario, end user assets will have an installed agent or will gain network access through a resource portal.
- Multi-cloud or cloud-to-cloud enterprises: Companies that use multiple cloud providers might see a situation where an application is hosted on a cloud service that is separate from the data source. In this case, an application hosted in one cloud should be able to connect directly to the data source in the second cloud, rather than force the application to tunnel back through an enterprise network. In this case, PEPs would be placed at the access points of each application/service and data source. These could be located in either cloud service, or even with a third cloud provider. Clients could access PEPs directly, with the ability for enterprises to manage access. One challenge here is that different cloud providers have their own methods for implementing the same functionality.
- Enterprise with contractors or non-employee access: For on-site visitors or contracted service providers that need limited access, a Zero Trust architecture would also likely deploy the PE and PA as a hosted cloud service, or on the LAN (if there is little or no use of cloud-hosted services). The PA ensures that non-enterprise assets cannot access local resources, but can access the Internet in order for visitors and contractors to be able to work.
Zero Trust challenges
Apart from some of the migration issues associated with moving from implicit trust to Zero Trust, there are several other issues security leaders should consider. First, the PE and PA components must be properly configured and maintained. An enterprise administrator with configuration access to the PE’s rules might be able to perform unapproved changes or make mistakes that can disrupt operations. A compromised PA could allow access to resources that would otherwise not be approved. These components must be properly configured and monitored, and any changes must be logged and subject to audit.
Second, because the PA and PEP are making decisions for all access requests to resources, these components are vulnerable to denial-of-service or network disruption attacks. Any disruption to the decision process could adversely affect a company’s operations. Policy enforcement can reside in a properly secured cloud environment, or replicated in different locations to help lower this threat, but it does not eliminate the threat completely.
Third, stolen credentials and malicious insiders can still do damage to a company’s resources. However, a properly developed and implemented Zero Trust architecture would limit the damage from such an approach, due to systems being able to figure out who was making the request and whether it was proper. For example, monitoring systems would be able to detect if a janitor’s stolen credentials were suddenly trying to access the credit-card number database.
Fourth, security officials need to be sure that adopting a Zero Trust strategy does not create a large amount of security fatigue, in which users are constantly being asked for credentials, passwords, and OS patch checks that would eventually affect productivity in a negative way. Here, a balance needs to be struck between the ability for employees and contractors to get their work done and making sure they are not attackers.
Zero Trust as part of a SASE service
Gartner has created a model called Secured Access Service Edge (pronounced “sassy”) that combines networking and network security services such as Zero Trust Network Access (ZTNA), software-defined wide area networks (SD-WAN), cloud access security brokers (CASB), Firewall as a Service (FWaaS) and Secure Web Gateways (SWG).
When delivered through a common framework, SASE can provide companies with consistent security and access to several types of cloud applications. This also gives companies a way to simplify their management, maximize network protection across their resources and no matter their location.
While Zero Trust can be deployed by enterprises that utilize cloud-based services, the SASE model can often provide more guidance through those other technologies.
Keith Shaw is a freelance technology journalist who has been writing for more than 20 years on a variety of technology topics, including networking, consumer electronics, robotics and the future of work.
