The Zero Trust Whiteboard.
Meera Krishnamurthy has twelve months to move a classified government workload off a perimeter-trust model. She has three weeks before she has to convince the principal engineer it can be done without breaking everything he built.
Meera Krishnamurthy is a security architect at Meridian Defence Systems, SC-cleared, eleven years in government contracting. She has been handed a twelve-month programme to migrate the department's OFFICIAL-SENSITIVE case management platform off a perimeter-trust network model toward zero trust. The programme board meets in eight weeks. The principal engineer, David Osei-Bonsu, has built and maintained the current architecture for six years. He is not opposed. He is unconvinced.
They meet in a south-block conference room with a whiteboard and a copy of the NCSC cloud security principles. David pulls up a diagram of the current estate on his laptop. Meera uncaps the marker and starts where she always starts: not with the solution, but with what the current model assumes.
"The entire design," she says, drawing a circle around the internal network, "is built on one assumption. If traffic is inside this boundary, it is trusted. That assumption is the problem."
The current model is classic perimeter trust — what the industry calls castle-and-moat. The moat is a pair of Cisco ASA firewalls operating in active/standby. Everything outside is untrusted. Everything inside is, implicitly, trusted. The DMZ exists as a buffer zone between those two states.
David points at the DMZ segment. "Walk me through why that's wrong."
Meera draws the DMZ (screened subnet) as a segment sitting between two firewall interfaces. The department's reverse proxy, email gateway, and public-facing API endpoint all live here. Traffic from the internet reaches the DMZ. Traffic from the DMZ to the internal network crosses the inner firewall on a default-deny basis, with specific permit rules for each documented flow. The DMZ is a rational design choice: it absorbs the internet-facing risk so the internal network doesn't have to. If the reverse proxy is compromised, the attacker is in the DMZ. They are not inside, where the case management database lives.
"The DMZ isn't wrong," Meera says. "It's insufficient. It protects north-south — traffic crossing the perimeter. It does almost nothing for east-west."
North-south traffic crosses the perimeter boundary: a user's browser hitting the public API, the email gateway relaying inbound post. East-west traffic moves laterally inside the network: an application server querying a database, a compromised workstation probing internal hosts. The current estate has a flat internal network. Once past the moat, an attacker can move laterally with minimal friction. The department had a near-miss fourteen months ago: a phishing compromise on a staff workstation that traversed to a file share containing unredacted witness statements before the anomaly was caught — not by any network control, but by a member of staff noticing the file access timestamps.
David is quiet for a moment. He knows about the near-miss. He was on the incident bridge call.
Meera draws VLANs on the whiteboard. VLANs — Virtual LANs are a logical segmentation of a single physical network into isolated broadcast domains. The case management servers go into VLAN 10. Developer workstations into VLAN 20. The integration bus and third-party supplier feeds into VLAN 30. The Palo Alto firewall at layer 3 enforces inter-VLAN routing: east-west traffic between segments must cross a controlled boundary, with explicit policy, logged. Lateral movement now has to earn its way through a firewall policy. That is the difference between an attacker pivoting in thirty seconds and an attacker generating alert traffic that a SOC can see.
"What about the suppliers?" David asks. "Some of them are hitting internal APIs directly. No proxy."
That is the next item on the whiteboard. A forward proxy sits between internal users and the internet, making requests on their behalf. Internal IP addresses are hidden from external servers. Web filtering and TLS inspection happen here — on this estate that is a Zscaler Internet Access deployment for outbound web traffic. A reverse proxy does the inverse: it sits in front of internal services and handles inbound requests from external clients. The F5 BIG-IP in the DMZ is the reverse proxy for the public-facing API. Suppliers hit the F5. They never see the internal application server. The internal server's address is never exposed. This is not just network hygiene — it is a data minimisation principle consistent with NCSC cloud security principle 9: secure user management.
David points at the server segment. "Our SC-cleared admins still need to reach the infrastructure directly. How does that work?"
Meera writes bastion host on the board. The jump server — hardened, minimal-footprint, running nothing except an SSH daemon and a PAM audit module — is the only host in the estate reachable by administrators. All session traffic is logged to a write-once audit store. Admin connects to the bastion first. From the bastion, they hop to the target host. The bastion has no internet access of its own. It is not registered in DNS. It has no open ports beyond TCP 22. If the bastion is the only path to infrastructure, then the bastion is the only thing that needs that attack surface hardened to that level. On this programme, the bastion is being replaced in phase two by Cloudflare Access with hardware-token MFA — an identity-aware proxy that enforces per-session authorisation without requiring a persistent SSH hop. But the concept is the same: one controlled gateway, total visibility, no implicit trust.
David draws a line between the two sites. "We've got a secondary processing site in Leeds. That link is MPLS today."
The MPLS link is site-to-site connectivity — two fixed locations connected by a dedicated encrypted path. The successor to MPLS here is a site-to-site VPN over internet bearers, running IKEv2/IPsec. The VPN establishes an encrypted tunnel; IPsec handles the encryption and authentication of traffic within it. Remote access VPN is distinct — it is the individual engineer connecting from a home network or a department-issued laptop from a hotel. On this estate, remote access runs Cisco AnyConnect with split tunnel configured: traffic destined for the 10.44.0.0/16 internal range routes through the encrypted tunnel; all other traffic goes direct to the internet. Full tunnel would route everything through the tunnel — more secure, higher latency, and unnecessary once a ZTNA layer is enforcing access at the application level regardless.
Meera pauses. "VPN's role in this architecture is declining. In eighteen months it may be gone entirely."
David raises an eyebrow. Meera draws a new section of the diagram. NAT — Network Address Translation is working at the perimeter firewalls: internal hosts carry RFC 1918 private addresses; the Cisco ASAs translate them to the department's allocated public IP range before traffic leaves the network. PAT — Port Address Translation multiplexes many internal hosts behind a single public IP using different source port numbers. This hides internal addressing from external networks and conserves public IP space. It is not a security control — NAT is not a firewall — but it is architectural hygiene that reduces accidental exposure.
David points at one segment on his laptop: a small, isolated enclave handling the most sensitive material — unredacted case files under active prosecution. "This one we're not migrating. Ever."
Meera nods. Some controls cannot be replaced by software policy. That enclave is air-gapped: no network interface, no wireless capability, no connection to any adjacent network. Data in and out moves by physically carried removable media through a documented, logged, two-person process. Air gaps are justified exactly here — the highest classification, the highest consequence of breach, the workload where the threat model includes nation-state actors with the patience and capability to probe for any network path. The rest of the estate does not meet that bar. Applying air-gap controls everywhere would make the department non-functional. Air gaps are not a scalable security strategy — they are a last resort for the genuinely irreplaceable.
The perimeter model assumes location equals trust. Zero trust assumes location is irrelevant. Every request — from inside the network, outside the network, from a cleared member of staff, from a compromised workstation — is treated as untrusted until identity, device posture, and authorisation policy say otherwise. — Story 17 · Network Architecture
Meera draws the target state on the right half of the whiteboard. Zero trust is not a product. It is an architecture principle, formalised by NIST SP 800-207, applied here under NCSC zero trust architecture guidance. The core axiom: never trust, always verify. Network location grants no privilege. Every access decision is evaluated against identity, device posture, and the specific resource being requested — evaluated at the time of the request, not assumed from a prior authentication.
The implementation has three layers. First, microsegmentation: the VLAN segmentation already discussed, extended by Palo Alto Panorama policy that enforces application-layer rules at east-west boundaries. A compromised host in VLAN 20 cannot reach the case management database in VLAN 10 without a policy permit, regardless of whether it has a valid IP route. Second, identity-aware proxy: Cloudflare Access sits in front of every internal application. Users authenticate with their smartcard-backed government identity, Cloudflare evaluates device posture via the WARP client, and access is granted per-application, per-session. The network path to the application is invisible to the user. Third, device posture: endpoints must present a current patch level, active antimalware, and disk encryption status before any application session is granted. A device that was compliant at 09:00 and failed a patch check at 14:00 loses access until remediated.
David is taking notes. "What about the SD-WAN project the network team started last year?"
SDN and SD-WAN are complementary. Software-defined networking abstracts the control plane from the physical hardware, letting policy be programmed centrally rather than configured device-by-device. SD-WAN applies that model to WAN links: the Leeds site connection can use MPLS, internet broadband, and 4G simultaneously, with traffic steered by policy rather than static routing. On this programme, SD-WAN is the transport layer. Zero trust is the access policy layer above it. They are not alternatives; they solve different problems.
Meera writes SASE at the top of the target-state diagram. Secure Access Service Edge is the converged cloud-delivered model that combines network and security functions: a Secure Web Gateway (SWG) for outbound web traffic inspection, a Cloud Access Security Broker (CASB) for visibility and control over cloud service usage, Zero Trust Network Access (ZTNA) replacing the VPN, and Firewall-as-a-Service (FWaaS) for network-layer policy enforcement. On this estate, Zscaler Private Access handles the ZTNA component; Palo Alto Prisma Access provides the SWG and FWaaS. The CASB layer sits above both, enforcing data loss prevention policy on cloud storage before a member of staff can upload a case file to an unsanctioned service.
David puts his pen down. "The perimeter still matters for the air-gapped enclave and the physical site boundary. But for the rest of it — I see the argument."
Meera writes the programme's first milestone on the board: VLAN segmentation live, bastion host replaced, device posture checks enforced. Twelve weeks. The DMZ stays — the public-facing API and email gateway still need that buffer zone between internet and internal network. The DMZ is not wrong; it is just no longer sufficient on its own. Zero trust and perimeter controls are not opposites. For the next twelve months, they will run in parallel, with the perimeter model gradually giving ground as each workload is migrated and each implicit trust assumption is replaced with a verified one.