Chapter 6 Β· Zero Trust

The Open Castle

NovaCorp's internal network was like a medieval castle: strong walls outside, but once you were inside, you could walk anywhere. One breach changed everything.

Inside the Firewall

The attacker had been on NovaCorp's network for six days before anyone noticed. They had compromised one marketing workstation via a phishing email. From there, the internal network was wide open β€” no segmentation, no internal authentication requirements, no monitoring between systems. They moved from marketing to HR, from HR to the finance servers, and finally to the backup systems. By the time the SIEM triggered an alert, 200GB of financial data had been exfiltrated.

"Once they got past the perimeter firewall," the CISO said grimly, "we had nothing else to stop them. We assumed everything inside was trusted."

"That assumption," said the incoming consultant, "is exactly what Zero Trust was designed to eliminate."

πŸ’‘ Zero Trust Principle"Never trust, always verify." No user, device, or system is trusted by default β€” regardless of whether it is inside or outside the network. Every access request must be authenticated, authorized, and validated before access is granted.

Separating What Data Does from How It's Controlled

The consultant started by explaining how NovaCorp's security devices would need to be restructured around two functional planes.

"Your data plane," she said, pointing to the network diagram, "is where actual traffic flows β€” frames, packets, NAT translations, encryption in transit. Your switches, routers, and firewalls process this traffic in real time."

"The control plane is different. It's where you define the policies β€” the routing tables, the firewall rules, the session policies. It manages how the data plane behaves. When you update a firewall rule, you're working in the control plane. When a packet travels through that firewall, it's moving through the data plane."

This separation applied to physical devices, virtual machines, and cloud security controls alike.

Context-Aware Verification

The next layer was adaptive identity. "Standard authentication asks: do you know the password? Adaptive identity asks: does everything about this login make sense?"

A user logging in from the same building they always use, on their registered device, during work hours β€” low risk. The same credentials, but from an IP address in China at 3 AM, on an unregistered device β€” high risk. Same password. Very different context. Adaptive identity uses these risk indicators to automatically demand stronger authentication when something looks anomalous.

NovaCorp's new system would evaluate: relationship to the organization (employee, contractor, vendor), physical location, device type, IP reputation, and time of access.

The Gatekeeper and the Judge

At the heart of NovaCorp's new architecture were two components. The Policy Enforcement Point (PEP) β€” the gatekeeper. All traffic passed through the PEP. It allowed, monitored, and terminated connections based on decisions it received.

But the PEP itself didn't make decisions. It forwarded access requests to the Policy Decision Point (PDP). Inside the PDP were two parts: the Policy Engine β€” which evaluated every access request against predefined policies, threat intelligence, and contextual data, and decided: grant, deny, or revoke. And the Policy Administrator β€” which took the engine's decision, generated access tokens or credentials, and instructed the PEP on whether to allow or block the connection.

"Think of the PEP as the security checkpoint at the airport," the consultant said. "The PDP is the intelligence system behind it β€” comparing names against watchlists, checking document validity, and radioing the checkpoint agent whether to let someone through."

Trust is Contextual, Not Absolute

NovaCorp's network was divided into security zones: Trusted (corporate offices), Untrusted (internet), Internal (data center), and departmental zones (Marketing, Finance, IT). Traffic from Untrusted to Trusted was automatically blocked. Traffic from Trusted to Internal was allowed under specific conditions. Department-to-department traffic required explicit authorization from the PDP.

"Zero Trust doesn't mean you never trust anything," the consultant clarified. "It means trust is earned, verified, and contextual β€” never assumed. Your Finance zone can trust your Finance users after they're authenticated, their device is verified, and the Policy Engine approves the session. That's very different from assuming everyone inside the firewall is safe."

βœ… The Core Lesson Zero Trust = Never trust, always verify. Separate data plane (traffic) from control plane (policy). Use adaptive identity for context-aware verification. PEP enforces, PDP decides (Policy Engine + Policy Administrator). Organize network into security zones. Reduce threat scope by limiting entry points.