Zero-trust principles — the model that replaces the perimeter

Perimeter security assumes that what is inside the perimeter is trusted. The firewall is the boundary; inside the boundary, hosts trust each other; outside the boundary, hosts are untrusted. Perimeter security worked when the network had a clear inside and a clear outside, when the inside was small, and when the threats were external.

Zero-trust assumes that no host is trusted by virtue of its location. Every request is authenticated; every authorisation is checked; every flow is treated as if it crosses an untrusted network. Zero-trust emerged when the perimeter dissolved — when remote work, cloud services, mobile devices, and partner integrations made the inside indistinguishable from the outside.

This lesson covers zero-trust as a security model: the principles, the threat model, the difference from perimeter security, and what changes for the firewall operator.

The four principles

Zero-trust has four principles. Each principle is a decision the operator makes; each principle has a control that implements the decision.

Never trust, always verify

Every request is authenticated. The source of the request — its IP address, its location, its network — does not grant trust. The trust is granted by the identity of the requester and the validity of the credential presented.

The principle in firewall terms: source IP is not a sufficient authorisation. A packet from 192.168.1.50 is no more trusted than a packet from 203.0.113.50 based on its source alone. The packet must carry credentials — a user identity, a device identity, a session token — that the firewall can verify.

Least privilege

Every authorisation is the minimum needed. The user who needs to read a file is not granted write access. The service that needs to call one API endpoint is not granted access to all endpoints. The firewall that needs to allow one port is not allowed to allow all ports.

The principle in firewall terms: rules grant the minimum access needed for the traffic to function. A rule that allows “any source, any destination, any port” is a violation of least privilege. The rule is broken into narrower rules, each granting access to the specific flows that need it.

Assume breach

The network is treated as if it has already been compromised. Lateral movement is expected. Insider threats are expected. The question is not “did the attacker get in?” but “what does the attacker see when they are in?”

The principle in firewall terms: segmentation is not optional. Every network segment is treated as if it contains a compromised host. East-west traffic between segments is restricted. A compromise in one segment does not automatically compromise other segments.

Continuous verification

Trust is not a one-time decision. Trust is verified continuously. A user authenticated at 09:00 is re-verified at 09:15. A device compliant at login is re-checked at intervals. A session valid at creation is re-validated throughout.

The principle in firewall terms: rules are not static. Authorisations are re-checked. A session that becomes invalid (the user logs out, the device is removed from the management system, the credential expires) is terminated.

$ configctl filter show 2>/dev/null | grep -E '^@' | head -10 && echo '---' && configctl filter show 2>/dev/null | grep -cE '^@.*any to any'

@0 pass in quick on igb0 inet proto tcp from 192.0.2.0/24 to any port = https
@1 pass in quick on igb0 inet proto tcp from 192.0.2.0/24 to any port = dns
@2 pass in quick on igb0 inet proto tcp from 192.0.2.0/24 to any port = ssh
@3 block in quick on igb0 inet from 192.0.2.99 to any
4

Threat model: what zero-trust is designed for

Zero-trust is designed for a specific threat model: the perimeter has been breached. The attacker is inside the network. The attacker may have compromised a user account, a device, or a service. The attacker is moving laterally, escalating privileges, exfiltrating data.

The perimeter-security model fails against this threat. Perimeter security concentrates controls at the boundary; once the boundary is breached, the inside is open. The attacker who breaches the perimeter has the run of the inside.

The zero-trust model assumes the breach is inevitable. The controls are inside the network, not just at the boundary. The attacker who breaches one segment finds the next segment defended. The attacker who compromises one account finds the next account requires re-authentication. The attacker who compromises one device finds the next device requires re-verification.

Zero-trust vs perimeter security

The differences:

A zero-trust firewall operator does not abandon perimeter security — the perimeter is still the boundary, the boundary still has anti-spoofing and default-deny. The operator adds zero-trust controls inside the perimeter: source restrictions on internal interfaces, identity-based rules where possible, microsegmentation between service tiers.

What changes for the firewall operator

The firewall operator’s decisions under zero-trust:

1. Source restrictions bind to identity. A rule that allows traffic from 192.168.1.0/24 is insufficient. The rule allows traffic from the source subnet regardless of which device on the subnet is sending. Under zero-trust, the source is bound to identity: only the device with the right identity on the right subnet is allowed.

2. Rules grant minimum access. A rule that allows “any to any on port 443” is too broad. The rule is broken into narrower rules that allow specific flows: the HR system to the HR vendor, the CRM to the CRM API, the development team to the development environment. Each rule is justified by the minimum access needed.

3. Segments contain breaches. A flat network is a zero-trust failure. The attacker who breaches one segment has access to every other segment. Under zero-trust, segments are defined by service tier, by trust level, by data sensitivity; each segment has its own rules.

4. Sessions are re-validated. A rule that allows a session for an indefinite period is a zero-trust failure. Under zero-trust, sessions have lifetimes; the firewall re-validates the session at intervals; an expired session is terminated.

The changes are not free. Source restrictions that bind to identity require an identity provider the firewall can query. Minimum-access rules require a documented inventory of flows. Segmentation requires network architecture work. Session re-validation requires session-tracking infrastructure.

Zero-trust theatre

Zero-trust theatre is the discipline of complex rules that look zero-trust-compliant but produce no security. The operator who adds identity-based rules but the identity provider is bypassed; the operator who adds segmentation but the segmentation is not enforced; the operator who adds session re-validation but the session is not actually re-validated.

The difference between zero-trust and zero-trust theatre is the operator’s ability to name the threat each control addresses and the evidence each control produces. The control that has a threat and an evidence trail is zero-trust. The control that has neither is theatre.

Summary

• Zero-trust principles: never trust, always verify, least privilege, assume breach, continuous verification.
• Zero-trust is designed for a threat model where the perimeter has been breached. The controls are inside the network, not just at the boundary.
• Zero-trust changes what the firewall operator builds: source restrictions bind to identity, rules grant minimum access, segments contain breaches, sessions are re-validated.
• Zero-trust theatre: complex rules that look compliant but produce no security. The difference from real zero-trust is the threat each control addresses and the evidence each control produces.