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 the device, not the end user, not the process. Everything must be authenticated, authorized, verified and continuously monitored.
Traditional security approaches are based on the concept of “trust, but verify.” The weakness of this approach is that once someone is authenticated, they are considered trusted and can move laterally to access sensitive data and systems that should be prohibited.
The Zero Trust principle changes this to “never trust, always verify.” The purpose of a Zero Trust architecture is not to make a system trusted or secure, but to eliminate the concept of trust entirely. The Zero Trust security model assumes that attackers are always present in the environment. Trust is never granted unconditionally or permanently but must be continually evaluated. 4G industrial router
The Zero Trust approach was developed as a response to years of traditional methods of how enterprise assets, resources and data are accessed. In the early days of computing, companies were able to protect their data by using firewalls and other security technologies that created a “security perimeter” around the data. Like medieval city walls, these techniques help protect what’s inside (mostly).
But boundaries quickly changed as employees, contractors and business partners began working remotely – accessing resources through cloud-based networks or using personally owned devices that were not always verified to be fully secure of. Additionally, there has been an increase in the deployment of Internet of Things (IoT) devices, which often provide automated access to network resources.
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 user experience. After authentication and authorization, users are granted access, but only to the resources they need to perform their jobs. If a device or resource is compromised, Zero Trust ensures the damage can be contained.
The good news for many companies is that they may already have invested in several Zero Trust enabling technologies. When adopting a zero trust approach, companies are more likely to need to adopt and implement new policies rather than install new hardware.
What is the basic concept of ZTNA?
Before you start deploying a zero-trust architecture, there are a few basic rules that your entire company must follow in order for the system to work properly.
– All data sources, computing services and devices are considered resources. Even employee-owned devices must be considered resources if they can access corporate-owned resources.
– All communications should be protected regardless of network location. Devices and users within the network are no more trustworthy than those outside the network perimeter.
– Grant access to resources on a per-session basis with the minimum permissions required to complete the task. Authentication to one resource does not automatically grant access to another resource.
– Access to resources is determined through a dynamic policy that includes the client identity, the state of the application, and possibly other behavioral and environmental attributes.
– Businesses must monitor and measure the integrity and security status of all owned and related assets. Continuous Diagnostics and Mitigation (CDM) or similar systems are required to monitor devices and applications. Patches and fixes need to be applied quickly. Assets found to have known vulnerabilities can be treated differently (including denying connections) than devices or assets deemed to be in the most secure state.
– Authentication and authorization will be strictly enforced before access is allowed and are subject to change. Authorization for one day does not guarantee authorization for the next day.
– Organizations need to collect as much information as possible about the current state of their assets, network infrastructure, communications, end users and devices to improve their security posture. Only with these insights can strategies be created, implemented and improved.
How to implement zero trust
Once these principles are understood and applied, companies can begin implementing a zero trust strategy. This includes the following five steps:
Identify resources that need protection. The terminology varies—some call it the “protective surface,” others the “implicit trust zone.” But it’s basically a well-defined area where zero trust processes will occur, depending on the business and its needs. Prioritizing protected areas can keep these areas small, at least initially.
Map the transaction flows for these resources. Companies need to determine who typically needs access to these resources, how they connect, and what devices they use to connect.
Build the architecture. This includes adding components that allow or deny access to these protected resources.
Create a zero trust policy that dictates user roles, authorization, and how users authenticate (multi-factor authentication is a must).
Monitor and maintain systems, making changes and improvements as needed.
What is a zero trust architecture?
After identifying a resource as protected, companies need to set up “checkpoints” that are responsible for deciding whether to allow or deny access. There are three main components, based on the terminology coined by NIST in its August 2020 Zero Trust Architecture document)
Policy Engine (PE). The Policy Engine (PE) is responsible for making decisions to grant or deny access to resources. It typically makes decisions based on corporate policies, but also takes input from external sources (including CDM systems, threat intelligence services) and trust algorithms. Once a decision is made, it will be recorded and the policy administrator will implement the action.
Policy Administrator (PA): The PA is responsible for establishing or closing communication paths between requesters (people or machines) and resources (data, services, applications). PA can generate session-specific authentication (or use tokens, credentials, passwords) as part of its process. If the request is granted, PA will configure the Policy Enforcement Point (PEP) to allow the session to start. If the request is rejected, PA will tell PEP to close the connection.
Policy Enforcement Point (PEP): A PEP enables, monitors, and ultimately terminates connections between requesters and resources. It communicates with the PA to forward requests and receive policy updates from the PA.
Other systems may provide input and/or policy rules, including CDM systems, industry compliance systems (to ensure that these systems are aligned with regulatory agencies), and threat intelligence services (to provide information on newly identified malware, software defects, or other reported attacks). information), network and system activity logs, and identity management systems (tracking updated roles, assigned assets, and other attributes).
Many of these systems feed data into trust algorithms that help make final decisions about requests to access network resources. The trust algorithm considers data from the requester, as well as many other metrics, as part of its decision-making. Examples of questions include but are not limited to:
Who is this guy? Is it a real person or a machine? (IoT sensors, for example)
Have they asked for this before?
What equipment do they use?
Has the operating system version been updated and patched?
Where is the requester located? (domestic, overseas, etc.)
Does this person have permission to view this asset?
Deployment plan of ZTNA
Every company is different, so how they approach Zero Trust will vary. Here are some common scenarios:
Businesses with satellite offices. Companies with employees working in remote locations or remote workers may need to host PE/PA as a cloud service. This provides better availability and does not require remote workers to rely on corporate infrastructure to access cloud resources. In this scenario, end-user assets will have agents installed or will have network access through the Resource Portal.
Multi-cloud or cloud-to-cloud enterprise: Companies using multiple cloud providers may see applications hosted on cloud services that are independent of the data source. In this case, applications hosted in one cloud should be able to connect directly to data sources in the second cloud, rather than forcing the application to tunnel back through the enterprise network. In this case, PEP will be placed at the access points of each application/service and data source. These can be located in a cloud service or even a third cloud provider. Customers have direct access to PEP, and enterprises can manage access rights. One challenge here is that different cloud providers have their own ways of achieving the same functionality.
Enterprises with contractor or non-employee access: For on-site guests or contracted service providers who require limited access, Zero Trust Architecture may also deploy PE and PA as managed cloud services, or on the LAN if there are few or Not using cloud hosting services). PA ensures that non-enterprise assets cannot access local resources but have access to the Internet so that visitors and contractors can do their work.
Zero Trust Challenge
In addition to 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 configured and maintained correctly. Enterprise administrators with configuration access to PE rules might be able to make unapproved changes or make errors that could disrupt operations. A compromised PA may allow access to resources that would not otherwise be approved. These components must be configured and monitored correctly, and any changes must be logged and audited.
Second, because PA and PEP are making decisions for all access requests to resources, these components are vulnerable to denial of service or network outage attacks. Any disruption to the decision-making process may adversely affect the Company’s operations. Policy enforcement can reside in a suitably secure cloud environment or be replicated to a different location to help reduce this threat, but it does not completely eliminate the threat.
Third, stolen credentials and malicious insiders can still cause damage to company resources. However, a properly developed and implemented Zero Trust architecture will limit the damage caused by this approach because the system will be able to determine who is making the request and whether the request is correct. For example, a surveillance system will be able to detect if a janitor with stolen credentials suddenly attempts to access a database of credit card numbers.
Fourth, security officials need to ensure that adopting a zero-trust strategy does not create massive security fatigue, in which users are constantly asked for credentials, passwords, and operating system patch checks, ultimately negatively impacting productivity. Here, a balance needs to be struck between the ability of employees and contractors to get their jobs done with ensuring they are not attackers.