CYBER LIBRARY
Explore the bootcamp
Connected systemsIntermediate

Zero trust

Understand resource-focused access decisions, identity and device evidence, and how zero trust works alongside existing controls.

3 min readUpdated 12 Oct 202610 connections
Markdown

Why location is not enough evidence

Zero trust is an architectural approach that avoids granting implicit trust solely because an account or device is inside a particular network or owned by an organization. Its focus is access to resources: who or what is requesting access, which resource is involved, and whether the available evidence supports the requested action.

NIST SP 800-207 is a foundational reference for the approach. The phrase does not describe one appliance, nor does it mean an organization can eliminate all trust. Systems still rely on identities, policy decisions, enforcement mechanisms, and the integrity of the evidence used to make those decisions.

An employee on two networks

Imagine an analyst accesses a reporting application from an office laptop. A traditional shortcut might treat the office network as sufficient evidence that the request is safe. That assumption becomes fragile when a device is compromised, an account is stolen, or a network includes systems with different responsibilities.

A resource-focused design checks the analyst's identity, the requested application, the relevant permissions, and the device conditions required by policy. The office location can remain useful context, but it does not automatically unlock every internal service. The same reasoning can support access from a remote location when the required evidence is present.

Draw the decision and enforcement points

For a learning exercise, separate the component deciding whether access is allowed from the component enforcing that decision. Then identify where their inputs originate. Account status may come from an identity service; device information from a management service; resource permissions from an application policy.

This diagram exposes dependencies. What happens if the device information is stale? What happens when the policy service is unavailable? Does the application have another route that bypasses the intended check? These are design questions that a product label cannot answer.

Least privilege still matters

A verified identity should receive only the access needed for the task. Least privilege limits the scope of a successful access decision. Identity and access management helps maintain the accounts and entitlements on which those decisions depend. Network segmentation can still reduce unwanted communication paths. These measures complement the architectural approach.

Ongoing evaluation also does not mean typing a password for every network packet. Different implementations use different signals and session policies. The useful requirement is to respond appropriately when important evidence changes, such as account suspension or a device falling outside the organization's policy.

Start with one resource

Choose a fictional payroll application and list its legitimate users, administrative tasks, data flows, and dependencies. Define a narrow access policy and test allowed and denied requests. Include a lost device, a removed employee, and an unavailable identity service in the exercise.

Explain the operational consequences of each decision. A policy that blocks essential work without a recovery route may create a different risk. Moving toward zero trust is a sequence of architecture and process improvements, supported by evidence that the intended boundaries actually hold.

GO TO THE SOURCE

References & further reading

Original explanations, with primary references for deeper study.

NIST: Zero Trust Architecture
EXPLORE THIS IDEA’S CONNECTIONS

A small part of a bigger picture.

9 notes · 13 connections
100%
Zero trust · depth 1
Drag to pan · Pinch or use +/− to zoom · Click to preview · Double-click to read
Browse notes as a list (9)
Start with a concept. Follow its connections.
Detection & responseAbuse Elevation Control MechanismElevation-control abuse bypasses or misuses mechanisms governing privileged execution.Making change happenAcceptance criteriaDefine observable conditions for a deliverable to be accepted.Security essentialsAccess controlUnderstand subjects, resources, permissions, and enforcement through a shared-drive example, including how access changes over time.Detection & responseAccess Token ManipulationAccess token manipulation changes or adopts operating-system security contexts.Risk & resilienceAccount Access RemovalAccount access removal disrupts legitimate users by changing, deleting, or restricting their identities.Evidence & investigationAccount DiscoveryAccount discovery enumerates identities available in a system or environment.Detection & responseAccount ManipulationAccount manipulation changes identity settings to preserve or expand access.Adversarial thinkingAcquire InfrastructureInfrastructure acquisition obtains domains, servers, or other resources used to support operations.Adversarial thinkingActive ScanningActive scanning probes target infrastructure to learn reachable services or weaknesses.Security essentialsAdversary in the middleAn intermediary may observe or alter a communication path.Security essentialsAESA symmetric block cipher whose safe use depends on its mode and implementation.Making change happenAgile deliveryUse short feedback cycles to adapt toward a useful outcome.