Jump to content

Zero trust: Difference between revisions

From Wiki@IndraStra
No edit summary
 
Line 260: Line 260:
<math>
<math>
\text{Identity}
\text{Identity}
+
\rightarrow
\text{Policy Evaluation}
\rightarrow
\text{Access Enforcement}
\rightarrow
\text{Resource}
</math>
 
Device security and monitoring can provide additional information to the policy-evaluation process:
 
<math>
\text{Device Security}
\text{Device Security}
+
+
\text{Policy Engine}
\text{Security Telemetry}
+
\text{Access Enforcement}
+
\text{Monitoring}
\rightarrow
\rightarrow
\text{Zero Trust Architecture}
\text{Policy Evaluation}
</math>
</math>


Line 284: Line 290:
\rightarrow
\rightarrow
\text{Resource}
\text{Resource}
\end{math}
</math>


Security telemetry can continuously feed information back into the policy-evaluation process.
Security telemetry can continuously feed information back into the policy-evaluation process.
Line 305: Line 311:
\text{Zero Trust}
\text{Zero Trust}
\rightarrow
\rightarrow
\text{Protect Individual Access to Resources}
\text{Protect Access to Individual Resources}
</math>
</math>



Latest revision as of 03:46, 21 August 2026

Zero trust is a cybersecurity security model based on the principle that access to information systems and resources should not be implicitly trusted solely because a user, device, application, or network connection is located within a trusted network boundary.

Instead, access is continuously evaluated using factors such as identity, device security, application context, resource sensitivity, and other relevant signals.

A simplified principle is:

Zero Trust→Never Trust AutomaticallyandContinuously Verify

The model is commonly summarized as:

Trust≢Network Location

Core principle

Traditional network security models often distinguish between trusted internal networks and untrusted external networks.

Zero trust removes or reduces this implicit distinction.

A simplified comparison is:

Traditional Model→Internal Network→Implicit Trust

Zero Trust Model→Explicit Verification→Conditional Access

Being connected to an organization's internal network does not, by itself, establish authorization to access a particular resource.

Identity verification

Zero trust places strong emphasis on verifying the identity of users, services, and devices before granting access.

A simplified access decision can be represented as:

A=f(I,D,C,R,P)

where:

  • A = access decision;
  • I = identity information;
  • D = device security or device posture;
  • C = contextual information;
  • R = requested resource;
  • P = applicable security policy.

The resulting decision may be represented as:

A∈{Allow,Deny,Challenge}

A challenge may require additional authentication or verification before access is granted.

Least privilege

A core principle of zero trust is least-privilege access.

Users and systems should receive only the permissions necessary to perform an authorized task.

A simplified relationship is:

Granted Privileges≤Required Privileges

Access can therefore be restricted by:

  • user identity;
  • role;
  • application;
  • resource;
  • operation;
  • time;
  • location;
  • device posture;
  • security risk.

Least-privilege access reduces the potential impact of compromised accounts or devices.

Continuous verification

Zero trust does not treat authentication as a one-time event that permanently establishes trust.

Instead, access decisions can be reevaluated as circumstances change.

A simplified process is:

Authenticate→Evaluate Context→Authorize→Monitor→Reevaluate

For example, an authenticated session may be restricted or terminated if the user's device becomes compromised or the observed activity deviates from applicable security policies.

Multi-factor authentication

Multi-factor authentication (MFA) is commonly used as part of zero-trust architectures.

Authentication can involve multiple independent factors, such as:

  • something the user knows;
  • something the user possesses;
  • something the user is.

A simplified representation is:

Authentication=f(F1,F2,…,Fn)

where each Fi represents an authentication factor.

MFA strengthens identity verification but is only one component of a zero-trust architecture.

Device security

Zero trust can incorporate the security condition of the device requesting access.

Relevant characteristics may include:

  • operating-system status;
  • security configuration;
  • encryption status;
  • endpoint protection;
  • software versions;
  • security patches;
  • device identity;
  • compliance with organizational policies.

A simplified access condition is:

Access=Identity Verified∧Device Compliant∧Policy Satisfied

Microsegmentation

Microsegmentation divides an organization's computing environment into smaller security zones and restricts communication between them.

A simplified network relationship is:

Network→{Segment1,Segment2,…,Segmentn}

Instead of allowing unrestricted communication across a network, policies can specify which identities, applications, or services may communicate with particular resources.

Microsegmentation can limit lateral movement after a system or account has been compromised.

Policy-based access

Zero-trust access decisions can be based on explicit security policies.

A simplified policy function is:

A=P(I,D,R,C,T)

where:

  • I = identity;
  • D = device state;
  • R = requested resource;
  • C = contextual information;
  • T = relevant temporal information;
  • P = authorization policy.

The same user may therefore receive different access decisions depending on the resource, device, context, or security condition.

Monitoring and logging

Zero-trust architectures generally require extensive monitoring and logging to support continuous assessment of access and activity.

A simplified security-monitoring process is:

Identity+Device+Network+Application+Resource Activity→Security Monitoring

Logs can be analyzed to identify anomalous behavior, unauthorized access attempts, compromised credentials, and other security events.

Data protection

Zero trust can be applied to protect access to data as well as network infrastructure.

Access decisions can incorporate the sensitivity of the requested data:

Access Control=f(Identity,Device,Resource Sensitivity,Context)

More sensitive resources can therefore be subject to stronger authentication and authorization requirements.

Encryption can also be used to protect data both in transit and at rest.

Zero trust architecture

A zero-trust architecture can include several interacting components:

Identity→Policy Evaluation→Access Enforcement→Resource

Device security and monitoring can provide additional information to the policy-evaluation process:

Device Security+Security Telemetry→Policy Evaluation

A simplified access flow is:

User/Device→Authentication→Policy Evaluation→Access Enforcement→Resource

Security telemetry can continuously feed information back into the policy-evaluation process.

Zero trust and network perimeter security

Zero trust does not necessarily eliminate traditional network security controls.

Firewalls, intrusion detection systems, network segmentation, endpoint protection, and other security technologies can remain components of a zero-trust architecture.

The principal distinction is the security assumption.

Perimeter Security→Protect the Network Boundary

Zero Trust→Protect Access to Individual Resources

Zero trust therefore shifts the focus from protecting a trusted network boundary toward protecting users, devices, applications, workloads, and resources.

Zero trust and remote access

Zero trust can support remote access by evaluating users and devices regardless of their physical network location.

A simplified model is:

Remote Location⇏Automatic Denial

and:

Internal Location⇏Automatic Trust

Access is instead determined by authentication, authorization, device posture, security policies, and other relevant conditions.

Zero trust and cloud computing

Cloud computing environments can increase the importance of identity-based and resource-level access controls because applications and data may be distributed across multiple cloud services, data centers, and networks.

A simplified model is:

User→Identity Verification→Policy→Cloud Resource

Zero trust can therefore be applied across cloud, on-premises, hybrid, and multi-cloud environments.

Benefits

Zero trust can provide several security benefits, including:

  • reduced reliance on network location as a security boundary;
  • stronger identity verification;
  • least-privilege access;
  • reduced lateral movement;
  • improved visibility into resource access;
  • stronger controls for remote and cloud environments;
  • improved containment of compromised accounts and devices.

Limitations and challenges

Implementing zero trust can introduce technical and organizational challenges, including:

  • complex identity and access management;
  • integration with legacy systems;
  • increased policy complexity;
  • device-management requirements;
  • extensive monitoring and logging requirements;
  • potential user friction;
  • implementation and operational costs;
  • difficulties determining appropriate access policies.

Zero trust is therefore an architectural and security strategy rather than a single product or technology.

Zero trust versus implicit trust

The fundamental distinction can be summarized as:

Implicit Trust→Trust Based on Context or Location

Zero Trust→Explicit Verification + Least Privilege + Continuous Evaluation

The objective is not to eliminate all trust but to make access decisions based on explicitly evaluated security conditions rather than assuming that a user or system is trustworthy merely because it has already entered a particular network.

See also