Segmentation Types — Side-by-Side Comparison
| Property | Physical | Logical (VLAN) | Virtual (Cloud/SDN) |
|---|---|---|---|
| Isolation mechanism | Separate physical hardware | 802.1Q VLAN tags on shared switches | Software-defined policies (VPC, security groups) |
| Security strength | Strongest — no shared medium | Strong — VLAN hopping risk if misconfigured | Strong — depends on correct policy definition |
| Cost | Highest — dedicated hardware per segment | Low — reuses existing switch infrastructure | Low — software only; pay-as-you-scale |
| Flexibility | Lowest — physical rewiring to reconfigure | High — reconfigure via switch management | Highest — programmatic; infrastructure-as-code |
| Cross-boundary traffic | Must traverse a physical firewall/router | Must be routed through a layer 3 device with ACLs | Governed by security group / firewall rules |
| Primary use case | ICS/SCADA, classified nets, high-compliance CDE | Enterprise LAN segmentation (standard deployment) | Cloud workloads, containerized apps, hybrid environments |
| Attack surface | No network attack path (air gap) | VLAN hopping via double-tagging or rogue trunk | Misconfigured security group rules (over-permissive) |
Three Reasons to Segment — With Examples
High-bandwidth applications interfere with other users when on a shared flat network. Isolating them prevents throughput degradation for both.
Examples: Video production workgroup, backup replication VLAN, VoIP subnet, storage traffic (iSCSI/NFS) isolated from user traffic.
Users should never reach database servers directly. The application tier must be the only path. Each tier boundary multiplies the attacker's required effort.
Rule: Only SQL and SSH should be permitted inbound to the database zone. All other ports blocked. Users → App tier only. App tier → DB tier only.
PCI-DSS mandates that systems handling cardholder data (the CDE) be isolated from all other network traffic. Segmentation defines the compliance scope.
Benefit: Systems outside the CDE segment do not fall under PCI audit scope. Also simplifies change control by limiting blast radius to a single zone.
ACL Rule Evaluation — How the First-Match Algorithm Works
ACL rules are evaluated top-down. The first rule that matches the incoming connection determines the outcome. Subsequent rules are not evaluated.
| # | Action | Source | Destination | Port | Purpose |
|---|---|---|---|---|---|
| 1 | PERMIT | 10.0.40.10 (admin jump) | Any | 22 (SSH) | Admin access — must be first to prevent lockout |
| 2 | PERMIT | 192.168.10.0/24 (users) | 10.0.20.0/24 (app tier) | 443 | Users → App servers HTTPS |
| 3 | DENY | 192.168.10.0/24 (users) | 10.0.30.0/24 (DB tier) | Any | Block users from database tier entirely |
| 4 | PERMIT | 10.0.20.0/24 (app tier) | 10.0.30.5 (SQL server) | 1433 | App servers to SQL only |
| 5 | DENY | Any | Any | Any | Implicit deny all — everything else blocked |
Allow List vs. Deny List — Decision Matrix
| Scenario | Best Approach | Why |
|---|---|---|
| Payment terminal (fixed app set) | Allow List | Only 2-3 apps ever run. Unknown app = guaranteed anomaly. Default-deny catches anything unexpected. |
| Developer workstation (many tools) | Deny List | Developers install new tools constantly. Allow list would block legitimate work. Deny list blocks known-bad without blocking unknown-legitimate. |
| Antivirus / anti-malware system | Deny List | By definition: allows everything except known malware signatures. Classic deny-list model. Cannot block unknown malware. |
| Industrial control system (SCADA) | Allow List | Fixed software environment. Any new execution is suspicious by definition. Safety-critical system requires maximum restriction. |
| Protection against zero-day malware | Allow List | Zero-day = no signature = not on any deny list. Allow list blocks it by default. Deny list allows it through. |
| General-purpose corporate endpoint | Both (layered) | Certificate + path rules (functional allow list) combined with AV deny list. Defense-in-depth covers known-bad and enforces publisher trust. |
Four Application Control Mechanisms — Quick Reference
| Mechanism | How It Identifies the App | Bypassed By | Update Impact |
|---|---|---|---|
| Hash | SHA-256 of the binary file | Nothing — renaming doesn't change the hash | Every update changes the hash → policy must be updated |
| Certificate | Digital signature publisher | Stolen or fraudulent code-signing certificate | Updates from same publisher auto-permitted — no policy change needed |
| Path | Directory the executable runs from | Write access to an approved directory; LOLBins (living off the land) | No impact — path doesn't change on updates |
| Network Zone | Network the device is connected to (public vs. private) | VPN satisfying zone check without true corporate network access; zone spoofing | No impact — zone check is runtime, not app-specific |