📖 Report📚 Glossary🗺️ Concepts💡 Examples🃏 Flashcards✅ Quiz🎯 Tricks
Chapter 55 · Examples

Segmentation and Access Control in Practice

Three-tier design walkthroughs, ACL lockout scenarios, allow/deny list decisions, and application control in action.

Example 1 · PCI-DSS Segmentation — Containing the Compliance Scope

A regional retailer processes credit card transactions at 40 store locations and via an e-commerce website. Without segmentation, every system that touches the network is potentially in scope for PCI-DSS audit — the auditor must review all of it. The security team designs a segmented architecture to contain the cardholder data environment (CDE) to the smallest possible footprint.

Before segmentation — flat network problem:

All store point-of-sale (POS) terminals, back-office workstations, HR systems, inventory management, and the corporate email server share one flat network. A PCI auditor must evaluate security controls on every system. An attacker who compromises the HR workstation can freely reach the POS terminals and the payment database directly, because there is nothing between them.

After segmentation — CDE isolation:

VLAN 10 — CDE (Cardholder Data Environment)
  Systems: POS terminals, payment application server, payment database
  ACL inbound: PERMIT only POS→App TCP 443; PERMIT App→DB TCP 1433; DENY ALL ELSE
  ACL outbound: PERMIT payment gateway API TCP 443 (specific external IP); DENY ALL ELSE

VLAN 20 — Corporate
  Systems: HR, email, inventory, back-office workstations
  ACL: DENY all traffic to VLAN 10 (no path to CDE from corporate)

VLAN 30 — Management
  Systems: Admin workstations, jump server for CDE maintenance
  ACL inbound to CDE: PERMIT only jump server IP TCP 22; DENY ALL ELSE

Security outcome: An attacker who compromises the HR workstation (VLAN 20) cannot reach any CDE system — the inter-VLAN ACL blocks all traffic from VLAN 20 to VLAN 10. The attacker would need to additionally compromise a management system in VLAN 30 and then use the jump server's authorized SSH path to reach CDE systems. Two separate compromises required instead of zero.

Compliance outcome: PCI-DSS audit scope shrinks from the entire network to VLAN 10 only. The auditor needs to validate controls on the POS terminals, payment app server, and payment database — not the 500 workstations in the corporate VLAN. The firewall and ACL rules between VLANs become audit evidence that the scope boundary is enforced.

Example 2 · The ACL Lockout — A Lesson in Rule Order

A network engineer is called in at 11:00 PM because users from the 10.0.50.0/24 guest Wi-Fi network have been port-scanning internal servers. The engineer logs into the core switch from their workstation at 10.0.50.88 (which is on the same guest subnet) to apply a block rule quickly.

Current ACL on the core switch management interface:

Rule 1: PERMIT src: 10.0.40.0/24 (management VLAN) dst: switch mgmt port: 22
Rule 2: DENY src: ANY dst: switch mgmt port: ANY
(implicit deny at end)

Engineer's intended change — block the guest VLAN from internal servers:

[Engineer adds to CORE SWITCH inter-VLAN ACL, not management ACL — thinks this is correct]

Rule 1 (new): DENY src: 10.0.50.0/24 dst: ANY port: ANY — block guest VLAN
Rule 2: PERMIT src: 10.0.50.88 dst: 10.0.10.1 port: 22 — [was: my admin access]
Rule 3: PERMIT src: 10.0.40.0/24 dst: ANY port: ANY

What happens immediately after saving: The engineer's own SSH session from 10.0.50.88 drops. The DENY at Rule 1 matches their workstation IP (in the 10.0.50.0/24 range) before Rule 2's specific permit is ever reached. The engineer is locked out of the switch they just modified. It is 11:30 PM, the switch is in a remote network closet, and there is no out-of-band management (no console access configured).

What the engineer should have done:

  1. Before making any change, move their workstation to a management VLAN address (or use the jump server in 10.0.40.0/24 that already has confirmed access).
  2. Use a commit-confirm mechanism (common on enterprise routers): configure confirmed 5 — the change auto-reverts after 5 minutes unless explicitly confirmed. If the SSH session drops, the rule reverts automatically.
  3. If neither is available, have a colleague with physical/console access on standby before making the change.
  4. Always verify that the permit rule for the active management session appears before any new broad deny rule in the ordered list.

Resolution: A colleague with physical access drives to the data center at 1:00 AM, connects via console cable, removes the bad rule, and restores access. The block was applied correctly an hour later from the management VLAN. Total cost: 90 minutes of downtime and an emergency trip.

Example 3 · Allow List vs. Deny List — Why Zero-Day Malware Breaks the Deny Model

Two companies receive the same phishing email on the same day. Both have antivirus software. The email contains a novel piece of ransomware with no existing signature.

Company A — Deny list only (standard antivirus):

User opens attachment → extracted executable runs from C:\Users\jdoe\Downloads\invoice.exe
AV scans binary → no signature match (zero-day, not in deny list)
AV result: CLEAN — execution permitted
Ransomware executes → begins encrypting C:\Users\jdoe\ and mapped network drives
3 hours later: 47 GB of files encrypted. Ransom note displayed.

Company B — Allow list with path-based and certificate controls (AppLocker):

User opens attachment → extracted executable attempts to run from C:\Users\jdoe\Downloads\invoice.exe
AppLocker path rule: execution from C:\Users\ is BLOCKED regardless of signature
AppLocker result: EXECUTION DENIED — path not in approved list
Event log: "AppLocker blocked invoice.exe (SHA256: a3f9...) in C:\Users\jdoe\Downloads\"
Security team notified of blocked execution attempt → phishing email identified and pulled

Company A suffered a full ransomware deployment. Company B blocked the same attack automatically — the malware was never on any deny list and the AV would have missed it too. The path-based allow list blocked it because user-writable directories are never approved execution locations, regardless of the binary's content, name, or signature.

What the allow list cannot do: If the attacker had first delivered a legitimate-looking application signed by a trusted certificate, or had written to an approved directory (which requires admin rights — preventing that is a separate control), the path-based rule would not have helped. Allow lists are the strongest control for the "drop and run from temp" attack pattern. They do not protect against living-off-the-land attacks using approved system binaries.

Example 4 · Application Hash Control — The Update Problem

A healthcare organization deploys AppLocker hash-based control for their electronic health record (EHR) application. The policy contains the SHA-256 hash of the current EHR client binary (version 8.4.2).

Day 1 — policy works as expected:

EHR v8.4.2 binary hash: a7f2c9... → Policy hash: a7f2c9... → MATCH → PERMITTED
Any other binary attempting to run as "EHR.exe" → hash mismatch → BLOCKED

Day 47 — vendor releases EHR v8.4.3 (security patch, required by compliance):

EHR v8.4.3 binary hash: b8e1d4... (new binary = new hash)
Policy hash: a7f2c9... (old version)
AppLocker check: b8e1d4... ≠ a7f2c9... → MISMATCH → BLOCKED
Result: 320 clinical workstations cannot open the EHR application after the update

The update was applied to all workstations overnight, but the AppLocker policy was not updated before the deployment. Every clinician arriving for the morning shift finds the EHR blocked. Patient care is disrupted for 2 hours until the policy is updated across all endpoints.

Process improvement: Hash-based application control requires that policy updates and software updates are coordinated as a single change. The correct workflow: (1) Vendor provides new binary. (2) IT computes the SHA-256 hash of the new binary. (3) AppLocker policy is updated in staging. (4) Updated policy is deployed to all endpoints. (5) New software version is deployed. Both deployments in the same maintenance window, policy deployment before software deployment.

Alternative: Use certificate-based control for the EHR application instead of hash control — the vendor signs their binaries with the same certificate across versions. All future EHR updates from the same publisher are automatically permitted without policy changes. Hash control is then reserved for the most critical or internally-developed binaries where the update frequency is controllable.

Exam Scenario · Segmentation and Access Control Design

Scenario: A financial services firm needs to design the network architecture for a new trading application. Requirements: (A) traders must be able to reach the trading application server; (B) the trading application server must be able to reach the market data database; (C) traders must not be able to reach the database directly; (D) only IT administrators may SSH to any server; (E) the firm must isolate the trading environment for regulatory compliance.

Answer — Design and ACL rules:

Segmentation: Three VLANs: VLAN 10 (Traders — 192.168.10.0/24), VLAN 20 (Trading App Servers — 10.0.20.0/24), VLAN 30 (Market Data DB — 10.0.30.0/24). Plus VLAN 40 (Admin/Management — 10.0.40.0/24). The compliance boundary is drawn around VLANs 20 and 30 — this is the regulated segment.

ACL between VLAN 10 and VLAN 20 (boundary firewall):

ACL between VLAN 20 and VLAN 30:

ACL for SSH access (requirement D):

Compliance (requirement E): The regulatory scope boundary runs between VLANs 10 and 20/30. The ACL enforcement at that boundary is the audit evidence. Compliance auditors review VLANs 20 and 30 only — not the 150 trader workstations in VLAN 10.