Example 1 · Zone Segmentation Containing a Breach — Retail Web Server Attack
A retail company runs an e-commerce platform. Their web server is publicly accessible. An attacker discovers a remote code execution vulnerability in the web application framework and gains shell access to the web server at 11:43 PM on a Saturday night.
Scenario A — No screened zone (flat network):
11:43 PM — Attacker executes RCE; shell on web server (192.168.1.50)
11:44 PM — Attacker runs network scan from web server
11:44 PM — Discovers: database server (192.168.1.10), file server (192.168.1.20),
domain controller (192.168.1.5), backup server (192.168.1.30)
11:46 PM — All on same flat network with no inter-host firewall rules
11:47 PM — Attacker connects to database (port 5432) — no firewall between web and DB
11:52 PM — Extracts full customer database: 2.1M records (names, addresses, credit cards)
12:30 AM — Attacker pivots to domain controller via pass-the-hash from database server
12:35 AM — Full domain admin compromise
Total time from web server breach to full domain compromise: 52 minutes
Data exfiltrated: 2.1M customer records
Scenario B — Proper screened zone (DMZ) implementation:
11:43 PM — Attacker executes RCE; shell on web server (10.10.1.50 — DMZ zone)
11:44 PM — Attacker runs network scan from web server
11:44 PM — Discovers: internal firewall boundary (no direct route to 192.168.x.x)
11:44 PM — Probes internal firewall: only port 5432 permitted, from web server IP only,
to database server IP, using specific service account
11:47 PM — Attacker connects to database via the permitted path
11:47 PM — Service account has SELECT only on e-commerce tables — no admin access
11:53 PM — Extracts order table: 14,000 orders (no stored credit cards — tokenized)
11:55 PM — Attempts to pivot to domain controller — blocked by firewall (no DMZ→trusted path)
11:56 PM — Attempts to probe other internal IPs — all blocked
12:01 AM — IDS sensor on DMZ boundary alerts on port scan behavior
12:03 AM — SOC analyst investigates; web server isolated
Total time from web server breach to containment: 20 minutes
Data exfiltrated: 14,000 order records (no payment data, no credentials, no internal access)
The lesson: The attacker's capabilities were identical in both scenarios. The difference was architecture: a screened zone with a restrictive internal firewall contained the blast radius of the compromise to a single zone. The web server was breached in both cases — but in Scenario B, the screened zone meant the attacker could not reach internal systems, and the service account's limited permissions meant the database itself was not fully exposed.
Example 2 · Honeypot Intelligence — Detecting Lateral Movement
A financial services company deploys three honeypots inside their trusted internal network: one that mimics a file server (\\FS-BACKUP-01), one that mimics a domain controller (DC-OLD-02), and one that mimics a database server (DB-ARCHIVE-03). All three are configured to generate high-priority alerts on any access.
Six weeks after deployment, the SOC receives an alert at 2:17 AM on a Tuesday:
ALERT: Honeypot \\FS-BACKUP-01 accessed
Source IP: 10.1.45.87 (assigned to: WORKSTATION-ACCOUNTING-14)
Access type: SMB file enumeration (listing shares)
Time: 02:17:43
User context: CORP\svc_payroll (service account)
SOC investigation:
02:18 — Analyst checks: WORKSTATION-ACCOUNTING-14 should be idle at 2 AM
02:19 — EDR shows: PowerShell process spawned at 02:14 AM — unusual
02:20 — PowerShell command: Invoke-Expression (encoded); lateral movement tool
02:21 — svc_payroll is not a user account — it's a service account for the payroll app
Service accounts should never be used for interactive logins
02:22 — Payroll application server (10.1.12.30) was compromised 4 hours earlier
Attacker extracted svc_payroll credentials from memory
Now using those credentials to enumerate internal network
02:25 — WORKSTATION-ACCOUNTING-14 isolated; payroll server isolated
02:30 — IR team engaged; credential rotation initiated for svc_payroll
Without the honeypot: lateral movement continues undetected
With the honeypot: 8-minute detection and containment
The lesson: The honeypot generated no false positives — there was no legitimate reason for any system to access \\FS-BACKUP-01. The alert was 100% reliable. The honeypot did not prevent the initial compromise of the payroll server, but it detected the attacker's lateral movement attempt immediately and allowed the SOC to contain the incident before the attacker reached payroll data or the domain controller.
Example 3 · Jump Server Preventing Administrative Credential Theft
An organization operates a data center with 80 Linux servers and 40 Windows servers. A security team evaluates two administrative access models and simulates an attack against each.
Model A — Direct access (no jump server):
Administrators: SSH/RDP directly from their workstations to each server
All 120 servers: SSH port 22 and RDP port 3389 open (accessible from admin subnet)
Simulated attack:
Attacker compromises WORKSTATION-ADMIN-03 (malware via phishing email)
Workstation has stored SSH keys for 14 Linux servers (admin's cached credentials)
Attacker uses keys to access 14 servers; finds one with sudo NOPASSWD configured
Full root on production database server in 23 minutes
Audit trail: nothing — direct SSH connections are not centrally logged
Attack surface: 120 servers × 2 admin ports = 240 administrative entry points
Model B — Jump server (bastion host):
All 120 servers: SSH/RDP accessible ONLY from jump server IP (10.0.0.5)
Administrators: must connect to jump server first; jump server enforces MFA
All sessions recorded (keystrokes + screen) and logged to SIEM
Simulated attack:
Attacker compromises WORKSTATION-ADMIN-03
Attacker tries SSH to production servers — all blocked (source IP not 10.0.0.5)
Attacker tries SSH to jump server — MFA challenge; attacker has password but not TOTP token
Access denied
SIEM alert: failed MFA attempt on jump server from WORKSTATION-ADMIN-03 at 3:47 AM
SOC investigates workstation; malware detected and removed
Attack surface: 1 jump server (hardened, MFA-protected)
Audit trail: complete — every session, every command recorded
The lesson: The jump server reduced the administrative attack surface from 240 ports across 120 servers to a single hardened host. The MFA requirement meant a compromised workstation could not be used to access any internal server — the attacker needed the second factor. The centralized logging gave the SOC both the alert and the investigation trail.
Example 4 · IPsec Site-to-Site VPN — Protecting Branch Office Traffic
A legal firm has a headquarters office and two branch offices. Attorneys at branch offices need access to the case management system at headquarters. The IT team evaluates two connectivity models.
Without encryption (plain MPLS, no overlay encryption):
Branch attorneys connect to case management system over MPLS WAN
Case management uses HTTP (unencrypted — legacy application)
Traffic path: Branch → MPLS provider → HQ
Simulated attack: MPLS provider employee (or a compromised provider router)
Installs passive tap on MPLS circuit between branch and HQ
Captures: all case management sessions (client names, case details, attorney notes)
Data classification: attorney-client privileged communications
Legal consequence: potential privilege violation; data breach notification requirement
Detection: none — passive tap generates no network alerts
With IPsec tunnel overlay:
IPsec tunnel established between branch VPN gateway and HQ VPN gateway
All branch-to-HQ traffic encrypted at IP layer before entering MPLS
Case management HTTP traffic: encrypted inside IPsec tunnel
Same simulated attack: passive tap on MPLS circuit
Captured packets: encrypted ESP (Encapsulating Security Payload) traffic
Attacker sees: encrypted blobs; source and destination tunnel endpoints
Cannot read: any application data, any case details, any user sessions
Result: data remains confidential despite physical network access
MPLS provider security irrelevant — transport is untrusted by design
The lesson: IPsec protects data in transit by assuming the underlying transport is untrusted. This is the correct model for any WAN connectivity — even private circuits like MPLS are operated by third parties. Network-level encryption ensures that a compromise of the network layer does not expose application data. The case management application required no changes — IPsec is transparent to applications.
Exam Scenario · Infrastructure Design Review for a University Hospital
Scenario: A university hospital is redesigning its network infrastructure after a security audit identified a flat network with no segmentation. The network currently has: an internet-connected edge router, 200 HVAC/building automation controllers (unpatched, end-of-support firmware), 45 clinical workstations accessing the EHR system, 12 research servers with sensitive study data, a public patient Wi-Fi network, an administrative office network, and a web server hosting the patient appointment portal. Design a zone architecture and answer the following questions.
A. How many security zones are needed, and what belongs in each?
At minimum, six zones are required for this environment:
- Untrusted (internet): Everything outside the hospital's control
- Screened/DMZ: Patient appointment web server (public-facing, must accept internet traffic, must not have access to EHR internal systems)
- Clinical zone (trusted, high security): Clinical workstations accessing the EHR system; highest security policy; strictly restricted access
- Research zone: Research servers with sensitive study data; separate from clinical to prevent clinical staff accidentally accessing research data and vice versa
- OT/Building zone: 200 HVAC controllers (unpatched, end-of-support — must be isolated from all clinical and IT systems)
- Guest Wi-Fi zone (untrusted): Patient public Wi-Fi; internet access only; no internal access; treated same as untrusted internet zone
- Administrative zone: Office staff, scheduling, billing; access to administrative systems but not clinical EHR data; not reachable from guest Wi-Fi
B. The web server hosting the patient portal needs to query the EHR database for appointment data. What is the correct zone placement and access rule?
The web server belongs in the screened zone (DMZ) — it must accept connections from the internet and therefore cannot be in the trusted zone. The EHR database belongs in the clinical zone (or a dedicated database zone behind the clinical zone). The access rule: permit only HTTPS queries from the web server's specific IP address to the EHR database's specific IP address on the specific database port (e.g., 5432), using a read-only service account that has access only to the appointment scheduling table — not to clinical records. No other traffic from the screened zone to the clinical zone is permitted. This is the minimal access path required for the business function.
C. The HVAC controllers run end-of-support firmware with a known critical vulnerability. What zone placement and access rules apply?
The HVAC controllers must be placed in the isolated OT/Building zone with no network path to any other zone. Because they cannot be patched, the compensating control is network isolation — if there is no network path to the vulnerability, it cannot be exploited remotely. The only permitted access is one-way from the building management workstation (which must also be in the isolated zone or a dedicated management zone) to the HVAC controllers on the HVAC management protocol port only. No internet access. No access from or to the clinical zone. No access from guest Wi-Fi. Physical access to the HVAC network segment should also be restricted.
D. A physician in the clinical zone needs to manage servers remotely during an on-call shift from home. What is the correct access architecture?
The physician should connect through a VPN concentrator that places them on the clinical zone network. The VPN should enforce MFA (password + token or certificate) before granting access. Once on the clinical zone via VPN, all administrative actions should be routed through a jump server — not directly to the servers. The jump server records all sessions. The VPN concentrator and jump server are configured to grant clinical zone access only — not access to the research zone, OT zone, or administrative systems the physician does not manage. When the on-call shift ends, the VPN session should be terminated by policy after a defined idle period.