Your Network with Zero Trust

The castle-and-moat model of network security assumed that once you were inside the walls, you were trusted. VPN in, you’re good. On the corporate network, you’re safe. That assumption was always fragile, and now it’s outright dangerous. Remote work obliterated the perimeter. Cloud services scattered your data across someone else’s infrastructure. Attackers who get past the moat — and they will — move laterally through flat networks with nothing stopping them because everything inside was “trusted.”

Zero Trust flips the model. Nothing is trusted by default. Every access request is verified, regardless of where it comes from. The network location doesn’t grant trust. The device doesn’t grant trust. Even the identity doesn’t grant trust on its own — it’s one factor among many, verified continuously. This isn’t a product you buy. It’s an architecture you build, one protect surface at a time.

DO / DON’T

DO:

• Start with your most critical assets — Zero Trust is a journey. Protect crown jewels first, then expand outward.
• Identify protect surfaces, not attack surfaces — Attack surfaces are infinite. Protect surfaces are specific, defined, and manageable.
• Map transaction flows before you build controls — Understand how data moves through your environment before you start blocking things.
• Enforce least privilege everywhere — Every identity gets the minimum access needed, for the minimum time needed. No standing privileges.
• Verify continuously — Authentication isn’t a one-time event. Re-evaluate trust based on behavior, device health, location, and context throughout the session.
• Log everything — You can’t verify what you can’t see. Comprehensive logging is foundational to Zero Trust.

DON’T:

• Don’t try to boil the ocean — Zero Trust across the entire enterprise at once is a recipe for failure. Iterate.
• Don’t think Zero Trust means zero VPN — VPN may still play a role. Zero Trust means VPN access alone doesn’t equal trust.
• Don’t buy a “Zero Trust product” and call it done — Vendors love slapping the label on existing products. Zero Trust is an architecture, not a SKU.
• Don’t forget about service accounts and APIs — Machine-to-machine communication needs the same verification as human access.
• Don’t skip the cultural change — Zero Trust changes how people work. Communicate the why before you change the how.

Step 1: Identify Your Protect Surfaces

The attack surface is everything exposed — every IP, every port, every application. It’s massive and constantly shifting. The protect surface is the opposite: the specific, critical things you need to defend.

Each protect surface contains one or more of the DAAS elements:

• Data — What sensitive data needs protection? PII, PHI, financial records, intellectual property, credentials.
• Applications — What applications process or access that data? ERP, CRM, email, custom applications.
• Assets — What infrastructure supports those applications? Servers, databases, domain controllers, SCADA systems.
• Services — What network services are critical? DNS, DHCP, Active Directory, NTP, SIEM.

Define each protect surface explicitly. “The customer database” is a protect surface. “The network” is not. NIST SP 800-207 defines Zero Trust architecture and its core tenets — start there for the authoritative framework.

Step 2: Map Transaction Flows

Before you can enforce policy, you need to understand how data flows. For each protect surface, map:

• Who accesses it — Which identities (human and machine) need access?
• What applications are involved — What’s the request path from identity to resource?
• When is access needed — Business hours only? 24/7? During specific processes?
• Where does the access originate — On-premises? Remote? Specific geolocations?
• Why is access needed — What business function does this access serve?
• How does the data flow — What protocols, ports, and intermediary systems are involved?

Document these flows. This map becomes the blueprint for your policies. Every allowed transaction flow becomes an explicit rule. Everything else is denied by default. CISA’s Zero Trust Maturity Model provides a staged approach for mapping and implementing these controls across five pillars: identity, devices, networks, applications, and data.

Step 3: Build Your Microperimeters

Each protect surface gets its own microperimeter — a segmentation gateway (next-generation firewall, software-defined perimeter, or identity-aware proxy) placed as close to the protect surface as possible.

Segmentation Gateway Placement

The segmentation gateway sits directly in front of the protect surface, not at the network edge. This is the fundamental architectural shift. In traditional security, the firewall protects the perimeter. In Zero Trust, the policy enforcement point protects the asset.

For a customer database:

• The segmentation gateway sits between the application tier and the database
• Only the specific application servers that need database access are allowed through
• Access is authenticated, authorized, and encrypted at this point
• All other traffic is denied — including traffic from other internal systems

Policy Engine + Policy Administrator

NIST SP 800-207 defines two core components:

• Policy Engine (PE) — Makes the trust decision. Evaluates identity, device health, behavior analytics, threat intelligence, and context to determine whether access should be granted.
• Policy Administrator (PA) — Executes the decision. Establishes or terminates the communication path between subject and resource.

These can be separate systems or combined in a single platform (many identity-aware proxies combine both functions).

Step 4: Create Kipling Method Policies

For each microperimeter, define policies using the Kipling Method — who, what, when, where, why, and how:

Default deny everything. Then add explicit allow rules for each documented transaction flow. If a flow wasn’t mapped in Step 2, it doesn’t get a rule.

Contextual, Continuous Verification

Trust isn’t binary — it’s a spectrum recalculated in real time:

• Device posture — Is the device managed? Patched? Encrypted? Running endpoint detection? A compromised device with valid credentials is still a threat.
• Identity confidence — MFA completed? Behavioral analytics normal? Impossible travel detected?
• Risk signals — Is the requested resource under active attack? Is the source IP associated with known threats?
• Session behavior — Has the session been idle? Has the access pattern changed mid-session?

Adaptive access policies adjust in real time. A request from a managed device on the corporate network with fresh MFA might get full access. The same identity from an unmanaged device in an unusual location might get read-only access or be blocked entirely.

Step 5: Monitor and Iterate

Zero Trust is never “done.” It’s a continuous cycle of monitoring, learning, and tightening.

What to Monitor

• All access decisions — Granted and denied. Denied requests reveal misconfigured policies or probing. Granted requests reveal whether policies are appropriately scoped.
• Lateral movement attempts — Traffic between protect surfaces that doesn’t match documented flows. This is the signal that either your flow map is incomplete or an attacker is moving.
• Device health changes — A device that was compliant at authentication but drops endpoint protection mid-session should trigger re-evaluation.
• Identity anomalies — Impossible travel, credential stuffing patterns, privilege escalation attempts.

Feed monitoring data back into your policy engine. Zero Trust architectures get smarter over time — but only if you close the feedback loop.

Iterating Outward

Once your first protect surface is secured, move to the next. Each iteration follows the same five steps: identify the protect surface, map flows, build the microperimeter, write policies, monitor.

Start with your highest-value assets. CISA’s Zero Trust Maturity Model defines progression from Traditional through Advanced to Optimal maturity across each pillar. You don’t need to be Optimal everywhere on day one. You need to be making measurable progress.

If It Already Happened

If you’ve experienced a breach where lateral movement was the primary escalation path — an attacker got in through one system and pivoted across your flat network to reach crown jewels — Zero Trust is the architectural answer.

Start the post-incident rebuild with the compromised protect surface. Map how the attacker moved. Every hop they made is a transaction flow that should have been denied. Build the microperimeter that would have stopped them. Then expand outward from there.

Report the incident through CISA and relevant regulatory channels. Use the breach as the business case for Zero Trust investment — the lateral movement path is the evidence.

Zero Trust isn’t a switch you flip. It’s a protect surface you identify, a transaction flow you map, a policy you write, and a control you enforce — then you do it again for the next one. Pick your most critical asset. Define its protect surface. Map who needs access and how. Build the microperimeter. Write the policy. Monitor. That’s your first iteration. Start there.